NX 200 

Network Executive 

Reference Manual 



Publication No. 4200036-00 
Revision A May 28, 1986 



Excelan Inc. 

2180 Fortune Drive 

San Jose, CA 95131 



Copyright ° 1986 Excelan, Inc. All rights reserved. No part of this publication may be 
reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any 
language or computer language, in any form or by any means - electronic, mechanical, 
magnetic, optical, chemical, manual or otherwise - without the prior written permission 
of Excelan, Inc., 2180 Fortune Drive, San Jose, CA 95131. 

Eixcelan makes no representations or warranties with respect to the contents hereof and 
specifically disclaims any implied warranties of merchantability or fitness for any 
particular purpose. Furthermore, Excelan reserves the right to revise this publication 
and to make changes from time to time in the content hereof without obligation of 
Eixcelan to notify any person of such revision or changes. 

EXOS is a registered trademark of Excelan, Inc. 

Excelan, and NX 200 are trademarks of Excelan, Inc. 

Ethernet is a trademark of Xerox Corporation. 

UNIBUS is a trademark of Digital Equipment Corporation. 

Multibus is a trademark of Intel Corporation. 

Q-bus and VMEbus is a trademark of Digital Equipment Corporation. 



NX 200 

Network Executive 
Reference Manual 



REVISION HISTORY 



FtEVISION DATE SUMMARY OF CHANGES 

A 05-28-86 Initial Release. 

NX 200 

Network Executive 
Reference Manual 
Publication No. 4200036-00 



- IV 



NX 200: Preface 



PREFACE 

This document describes the NX 200 Network Executive. It covers information 
necessary to integrate the EXOS Intelligent Ethernet Controller in a computer 
system, and to design software both for the host and the EXOS Intelligent Ethernet 
Controller. Ethernet and the various supported buses are described in readily 
available documents; this manual makes no special effort to explain these 
standards. 

By design, the NX 200 operating system kernel insulates user protocol software 
from hardware implementation details. This approach simplifies software design, 
and facilitates portability to future products. Therefore this manual primarily 
describes the NX 200 kernel, with reference to hardware design only where 
necessary. It is intended only as a reference manual, and does not undertake to 
explain the product's design philosophy. 

The following documents provide related reference and study material for NX 200 

users. 

NX 200, which is designed to be used in conjunction with the EXOS 
Intelligent Ethernet Controller, conforms to the following specification: 

[1] Carrier Sense Multiple Access with Collision Detection (CSMA/CD) 
Access Method and Physical Layer Specifications (Standard 802.3- 
1985/ International Standard 8802/3), The Institute of Electrical and 
Electronics Engineers, Inc., 1985. 

[2] The Ethernet: A Local Area Network: Data Link Layer and Physical 
Layer Specifications, Document no. T588.B/1 080/1 5K, Intel Corp., 
September 1980. 

[3] The Ethernet: A Local Area Network: Data Link Layer and Physical 
Layer Specifications, Version 2.0, November 1982 

NX 200 uses the services of Intel's 82856 LAN Coprocessor (present on the 
EXOS Intelligent Ethernet Controller board), for implementation of Ethernet 
Data Link protocol: 

[4] LAN Components User's Manual, Document No. 230814-001, Intel 
Corp., 1984. 

NX 200 code and user written protocol software executes on the EXOS 
Intelligent Ethernet Controller, which uses an Intel 80186 CPU. 

[5] iAPX 86/88, 186/188 User's Manual, Document No. 210911-001, 
Intel Corp., 1983. 

The following reference describes the C language, which is used for 
procedural specifications in this manual: 

[6] Kernighan, B.W. and Ritchie, D.M, The C Programming Language, 
Prentice-Hall, Englewood Cliffs, New Jersey, 1978. 

The following reference describes the ISO Open Systems Model: 

[7] Reference Model of Open Si/stems Interconnection, Document no. 
ISO/TC97/SC16 N227, June~1979. 
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Chapter 1 of this manual outlines the principle features of NX 200, and describes 
conventions and restrictions which are crucial to successful application of the 
NX 200 operating system kernel. 

Chapter 2 describes initialization of the EXOS 201 Intelligent Ethernet Controller 
for Multibus systems, including software download from the host. 

Chapter 3 describes initialization of the EXOS 202 Intelligent Ethernet Controller 
for VMEbus systems, including software download from the host. 

Chapter 4 describes initialization of the EXOS 203 Intelligent Ethernet Controller 
for Q-Bus systems, including software download from the host. 

Chapter 5 describes initialization of the EXOS 204 Intelligent Ethernet Controller 
for UNIBUS systems, including software download from the host. 

Chapter 6 discusses using NX 200 in the intelligent link level controller mode. In 
this mode, no software is downloaded, so that only glancing reference to Chapters 
7 through 9 will be necessary. 

Chapters 7, 8, and 9 describe the NX 200 firmware, which provides support for 
software downloaded to the EXOS intelligent Ethernet controller. Chapter 7 
describes the real-time, multitasking OS kernel services, and describes the 
programming environment aboard the EXOS intelligent Ethernet controller. 
Chapters 8 and 9 cover the Ethernet and host interface facilities, which are 
implemented in NX 200. They are broken out into separate chapters because 
NX 200's design makes them conceptually detachable. 

Chapter 10 defines the NX 200 kernel calls, and is intended for ready reference 
once NX 200 services are understood functionally. 

Chapter 1 1 describes NX 200's network bootstrap protocol, which can be used to 
automatically download software to the EXOS Intelligent Ethernet Controller over 
the Ethernet at initialization time. 

Appendix A describes the self-diagnostics and configuration error messages 
performed by the NX 200 firmware. 
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Chapter 1 
INTRODUCTION 



1.1. OVERVIEW 



Excelan's NX 200 Network Executive is a high performance, multitasking, 
message-oriented, operating system kernel especially designed for use with 
Excelan's EXOS 200 Series Intelligent Ethernet Controller boards. Additionally, 
it contains modules for diagnostics for EXOS boards, interfaces to the host and 
Ethernet, network bootstrap code, and Data Link Controller functions. 

NX 200, which provides software access to Ethernet/IEEE 802.3 networks, is 
supplied as firmware resident on two 16-kbyte EPROMS that are an integral part 
of each EXOS 200 Series board. Accordingly, NX 200 Network Executive is 
also referred to as NX 200 firmware. 

In a typical local area network (LAN) based on Ethernet/IEEE 802.3 standard, a 
host computer system is connected to the network through an EXOS board and 
a transceiver. The host can then operate in two basic modes: front-end and 
link-level. 

In the front-end processor mode, the host system downloads protocol software 
to the EXOS board at initialization time (or optionally, the EXOS Intelligent 
Ethernet Controller board bootstraps itself from the Ethernet). This software 
then uses NX 200's real-time, multitasking process management services and 
I/O drivers to control the EXOS board's Ethernet interface and manage 
communications with the host system. Standard protocol modules for the EXOS 
intelligent controller, such as the DARPA TCP/IP protocols, are available from 
Excelan. Figure 1-1 shows such an implementation in relation to the ISO Open 
Systems Integration model. 

Alternatively, users can develop, or port, their own protocols to run under NX 
200 on the EXOS board. This manual contains all information required to write 
software for the EXOS intelligent controller utilizing the NX 200 operating system 
function calls. 

In the Link-level controller mode; NX 200 firmware brings the EXOS board's 
Data Link controller functions out to the host interface. This is useful for 
applications where host-resident protocol software has already been developed, 
or where it is not otherwise feasible to download high-level protocols to run on 
the EXOS board. The host system obtains Data Link services through standard 
NX 200 request/reply messages; the EXOS board's RAM being entirely 
available for buffering packets. 

NX 200 is designed to support network protocol software, such as TCP/IP, that 
executes on Excelan's EXOS Intelligent Ethernet Controller. It provides 
multitasking, message-oriented operating system environment that includes a 
set of kernel calls and several data structures for communication between the 
host and the network. 

An application running on the host system communicates with the EXOS board 
primarily through request and reply messages located in host memory 
accessible from the host bus. NX 200, which directly manages the EXOS board 
resources through the on-board CPU, interprets the request messages and 
generates the replies, while supporting execution of high-level network protocols 
software on the EXOS board. 
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Figure 1-1 : An EXOS Board Front-End Processor Mode Implementation 



NX 200 provides a set of kernel calls, which perform system tasks necessary for 
the processing and/or transfering of data between the host and EXOS intelligent 
controller board, as well as, execution of user processes, and system and 
interprocess communication. 

NX 200 also includes functions that assist in network management, determine 
the Ethernet controller mode, define which memory locations to accept, provide 
host data order conversions, and collect network statistics. 

Programs and processes (that is, protocol software) intended to be executed 
under NX 200 can be written in any language compatible with the Intel 
80186 CPU. 
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Communication between NX 200 and the host is transacted via an NX 200 
system process that passes messages through circular, singly-linked buffers in 
shared host memory. Two ring buffers are shared by the host and NX 200 
firmware, one for each direction of transfer. Once NX 200 has been configured 
and initialized, these buffers serve all further communications with the host. 
This includes communication with downloaded protocol code, link level controller 
mode service requests, and software download. 

Network and interprocess communications are supported primarily by mailboxes. 
A user process obtains system process services by sending a request message 
to a system mailbox associated with the desired service. Additionally, processes 
can "share" data utilizing the mailbox calls, allowing processes to communicate 
with each other. The system mailboxes are created by NX 200 at initialization. 
Process mailboxes for communication and synchronization, like processes, can 
be created or deleted by the user. 

NX 200 accesses host bus memory by mapping part of its own CPU's address 
space to bus memory addresses. Sharing or accessing objects, messages, 
processes and other data can be performed, without jeopardizing portability, by 
directly utilizing the NX 200 memory access mechanisms. 

The NX 200 self-diagnostic tests, which are performed at host initialization time, 
exersise and verify the hardware and software components of the EXOS board 
and host interface. Included in the self-diagnostics are such tests as, memory 
reads and writes, send and receive, CRC, hard and soft interrupts, and a 
checksum of the NX 200 firmware. If an error occurs or a test fail, an error code 
is flashed on one of the three LEDs present on the EXOS board. These error 
codes are also useful for debugging procedures in user-created software. 

1.2. NX 200 FIRMWARE DESCRIPTION 

NX 200 resides in 32-Kbytes of EPROM memory, two 16-Kbyte EPROMs, which 
resides at the high end of the 1M byte address space of the CPU. NX 200 data 
structures use 4K of the RAM space; the rest is available for higher level 
software. Figure 1-2 illustrates the NX 200 software architecture. 

Principle Features 

• Self-diagnostics for testing the integrity of EXOS 200 Series board 
hardware. 

• Booting process that allows higher level software to be downloaded 
either from the host or from the network. 

• A real-time kernel that provides a multitasking environment, enabling 
the protocol software to be constructed in a structured manner as a 
set of cooperating processes. 

• Device drivers for the Ethernet controller and host computer 
interface. Access through message queues simplifies pipelined 
communications. 

• Supports network management functions by collecting network 
statistics. 

• Allows the EXOS 200 Series board to be used as a simple Data Link 
controller, giving direct access to the network without downloading 
any software. 
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Figure 1-2: NX 200 Software Architecture 



1.3. EXOS INTELLIGENT ETHERNET CONTROLLER HARDWARE DESCRIPTION 

Figure 1-3 shows a block diagram of the EXOS Intelligent Ethernet Controller 
logical arrangement. Architecturally, the EXOS 200 Series board consists of two 
loosely-coupled elements: an Ethernet Data Link Level controller, and a 
microprocessor-based protocol processing engine. These components 
communicate with each other through an internal bus and dual-ported RAM. 
Components of the protocol processing engine occupy the left half of the block 
diagram; the Ethernet controller occupies the right half. 

NX 200, uses the 82586 LANCoprocessor on the EXOS 200 Series board to 
implement the Ethernet Data Link protocol. In order to insure that the CPU is 
fully available for front-end processing applications, functions such as address 
recognition, CRC check, and buffer chaining are managed in hardware. The 
protocol processing engine is supported by on-board RAM. Two 16-Kbyte 
EPROMs contain Excelan's NX 200 firmware. For additional hardware 
descriptions and features refer to the applicable EXOS Intelligent Ethernet 
Controller Reference Manual. 
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Figure 1-3: EXOS Intelligent Controller Block Diagram 



1.4. ETHERNET COMPATIBILITY 

The NX 200 operating system kernel functions conform fully with the IEEE 
Standard 802.3. NX 200, in conjunction with the EXOS 200 Series board, is 
also compliant with Ethernet version 1.0 (September 1980) and version 2.0 
(November 1982) specifications published by DEC, Intel and Xerox. Integrated 
with the EXOS 200 Series Intelligent Ethernet Controller board and a standard 
Ethernet transceiver, it provides all Data Link and physical layer services. 
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1.5, COMPATIBLE HOST BUSES 

The EXOS Intelligent Ethernet Controller boards listed below are currently 
available for the indicated buses. 



• EXOS 201 for Multibus systems 

• EXOS 202 for VMEbus systems 

• EXOS 203 for Q-bus systems 

• EXOS 204 for UNIBUS systems 

The following sections describe NX 200s compatibility and compliance with the 
currently supported buses. 

1.5.1. Multibus Compatibility 

The NX 200 operating system kernel, in conjunction with the EXOS 201, 
Intelligent Ethernet controller, conforms with IEEE 796 (Multibus) specifications, 
as a 16-bit master. Compliance is D16 M24 116 V0 L (16-bit transfers, 24-bit 
addressing, and non-bus vectored interrupts). 

1.5.2. VMEbus Compatibility 

The NX operating system kernel, in conjunction with the EXOS 202 Intelligent 
Ethernet Controller conforms with VMEbus specifications (by Mostek, Motorola, 
and Signetics) as an Option D16, A24 VMEbus (16-bit) master. IEEE P1024 
compliance is 8-bit and/or 16-bit transfers, 24-bit addressing, and bus-vectored 
interrupts. 

1.5.3. Q-bus Compatibility 

The NX operating system kernel, in conjunction with the EXOS 203 Intelligent 
Ethernet Controller conforms with Q-bus (also known as LSI-11 BUS) 
specifications by DEC as a 16-bit master. Compliance is 8-bit and/or 16-bit 
transfers, 22-bit addressing, and bus-vectored interrupts. 

1.5.4. UNIBUS Compatibility 

The NX operating system kernel, in conjunction with the UNIBUS version of the 
EXOS Intelligent Ethernet Controller conforms with UNIBUS specifications by 
DEC as a 16-bit master. Compliance is 8-bit and/or 16-bit transfers, 18-bit 
addressing, and bus-vectored interrupts. 

1.6. NX-TO-HOSTBUS INTERFACE 

The following sections provide information that describes bus system memory 
space accessibility to NX 200. In each case, access to system memory space 
differs according to individual bus-type specifications. 

The EXOS 200 Series boards and host processors can interrupt each other by 
writing or reading an I/O port. The EXOS 200 Series board also provides a 
status bit, in case interrupt polling is required. For additional information refer to 
the applicable EIXOS Intelligent Ethernet Controller Reference Manual. 
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1.6.1. Multibus Interface 



NX 200 can access the entire Multibus system memory space (16 Mbyte) and 
the full 64K I/O space, as a 16-bit bus master. During initialization, an additional 
one-byte communication path is provided from the Multibus to the EXOS 
processor via an I/O port. This path is used to transmit the address of a 
communication area in the shared Multibus memory. 

The board generates non-bus vectored interrupts to interrupt the host. Interrupt 
priority can be set via jumper selection. 

1.6.2. VMEbus Interface 

NX 200 can access the entire 16 Mbytes VMEbus system memory space as a 
16-bit bus master. A One-byte communication path is provided from the 
VMEbus to the EXOS processor via a memory-mapped I/O port. This is used 
during initialization to transmit the address of a communication area in the 
shared VMEbus memory. 

The board generates bus-vectored interrupts to interrupt the host. Interrupt 
priority can be set from level 4 to level 7, via jumper selection. 

1.6.3. Q-bus Interface 

NX 200 can access the entire Q-bus system memory space (4 Mbyte) including 
the full 8-Kbyte I/O space, as a 16-bit bus master. A One-byte communication 
path is provided from the Q-bus to the EXOS processor via an I/O port. This is 
used during initialization to transmit the address of a communication area in the 
shared Q-bus memory. 

The board generates bus-vectored interrupts to interrupt the host. Interrupt 
priority is set from level 4 to level 7, via jumper selection. 

1.6.4. UNIBUS Interface 

NX 200 can access the entire UNIBUS system memory space (256-Kbytes) 
including the full 8-Kbyte I/O space, as a 16-bit bus master. A One-byte 
communication path is provided from the UNIBUS to the EXOS processor via an 
I/O port. This can be used during initialization to transmit the address of a 
communication area in the shared UNIBUS memory. 

The board generates bus-vectored interrupts to interrupt the host. Interrupt 
priority can be set from level 4 to level 7, via jumper selection. 

1.7. ETHERNET FUNCTIONS 

Together, NX 200 and an EXOS 200 Series board perform all physical and Link 
Level Ethernet functions except for transceiver functions. The functions 
performed include: 

• Serial/parallel and parallel/serial conversion 

• Address recognition 

• Framing and unframing of messages 

• Manchester encoding and decoding 
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• Preamble generation and removal 

• Carrier sense and deference 

• Collision detection and enforcement, including jamming, backoff 
timing and retry 

• FCS (CRC) generation and verification 

• error detection and handling 

1.7.1. Address Recognition 

Each board has a unique 48-bit Ethernet address, which is stored in EPROM 
(host software can override this address at run time). Recognition of physical, 
broadcast and multicast addresses is fully supported. Up to 252 multicast 
addresses can be assigned to a station; a very efficient filtering scheme 
reduces processing overhead. The EXOS 200 Series board also provides a 
promiscuous mode, in which it accepts all addresses. 

1.7.2. Frame Format 

Link level frames are formatted as per the Ethernet specification, with a 
preamble (64 bits) providing synchronizing sequence, destination address (48 
bits), source address (48 bits), message type (16 bits), data (46 to 1500 bytes) 
and FCS (32 bits). The preamble is generated and removed in hardware. 
Generation and checking of the Frame Check Sequence (FCS) is also handled 
in hardware. 

1.7.3. Error Handling 

The EXOS 200 Series boards handle all Ethernet error conditions, including 
CRC, alignment, and length errors. Packets containing these errors can 
optionally be received. Refer to the applicable EXOS Intelligent Ethernet 
Controller Reference Manual for further details. 

1.7.4. High Level Protocol Support 

NX 200 Network Executive Firmware supplied with the board provides simplified 
Ethernet and host interface device drivers, and a multitasking environment for 
high-level network protocols. 

On-board processing power supports execution of the higher level 
communications protocols, beyond the Ethernet link level. The elements of this 
programming environment are: 

• 32 Kbytes of EPROM, containing NX 200 firmware 

• 8 MHz CPU, with on-chip clock timer and interrupt controller, 
operating at 8 MHz 

• 128K dual-port RAM (256K and 51 2K available) 

1.8. INITIALIZATION 

Upon EXOS 200 Series board reset, the NX 200 firmware performs a series of 
self tests which confirm hardware integrity. In case of failure, the firmware 
communicates diagnostic codes through an LED display. After successful 
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completion of the tests, NX 200 either boots itself from the Ethernet, or awaits 
initialization by the host system, depending on a board jumper option. 

If the jumper selects initialization by a host system, the host then uses a 
configuration message to select NX 200s mode of operation, and specify 
several other parameters. The host can download software directly, tell NX 200 
to boot itself from the Ethernet, or select link level controller mode. If 
initialization includes downloading software, NX 200 spawns a process and 
enters the front-end processor mode of operation. 

The following sections describe the execution environment for software which is 
downloaded to the EXOS 200 Series board. 

1.9. MULTITASKING SUPPORT 

NX 200 includes a real-time kernel that implements a multitasking environment 
for construction of higher level software in a modular manner. This kernel is fast 
by design, and imposes very little overhead. It supports two types of objects - 
processes and mailboxes. The number supported of either object is 
configurable at start-up time. 

A process is a unit of execution in the conventional sense. All processes share 
the same memory address space and can thus communicate via shared 
memory. Other than for NX 200s reserved memory there are no restrictions on 
how memory is used. Processes access NX 200 functions by executing the 
CPU's "INT n" instruction, where n is a 2-digit number that identifies the service 
being requested. 

A priority-based preemptive round robin scheduling algorithm allocates CPU 
time among processes. As many as 256 priority levels are supported, and the 
highest priority executable process will always be scheduled. Among processes 
of the same priority, CPU time is allocated in time slices. A time slice is either 
infinity, or between 1 and 254 ticks, where each tick is 20 milliseconds. Any 
process can examine and change the priority and time slice of any process. 
Whether a process is executable is determined solely by a sleep count, from 
to 64K, and driven by the same clock as the time slice. Through this parameter, 
any process can suspend, delay or resume any other process. 

Interprocess communication and synchronization are implemented through 
mailboxes. Messages sent or received from the mailboxes can be either null or 
pointers to buffers in the common memory. A message buffer format is arbitrary 
except for the first field, which NX 200 uses to chain the messages in the 
mailbox queue. The sending and receiving of messages is fully synchronized. 
A process executing a receive call on a mailbox can specify the maximum time 
interval it is willing to wait. Waiting is implemented with the sleep count 
mechanism described above. If the specified time expires before a message 
arrives the process is resumed and given an error code instead of a message. 
If only null messages are used, then the mailbox is identical to a conventional 
semaphore. The receive operation in this case is equivalent to the P operation 
and the send operation is equivalent to the V operation. The mailbox can be 
thus used as a synchronization mechanism both for a producer-consumer 
relationship and a critical section. 
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In addition to the mailbox, the NX 200 has a simpler and more efficient 
synchronization mechanism intended for short critical sections: the process lock. 
This operation postpones scheduling decisions until a corresponding unlock is 
executed, thereby excluding all other processes from running. Calls to lock can 
be nested up to 32K levels deep. 

1.10. THE CLOCK 

NX 200s clock driver provides the abstraction of a 64-bit clock with a resolution 
of 20 milliseconds. Processes can read or set the time at will. On initialization 
the clock is set to zero. 

1.11. HOST INTERFACE 

NX 200 provides a uniform interface to the host regardless of the nature of the 
actual hardware host interface. The abstraction of the host is presented as a 
mailbox and read/write operations on host memory. The mailbox acts as a 
source and sink for messages and also provides synchronization between the 
processes on the host and the processes controlled by NX 200. 

This interface appears to host system software as two circular queues of 
message buffers, one for each direction of transfer. Sending a message to the 
NX 200 host mailbox causes the message to be transferred to the host memory, 
where it can be read by the host processes. Similarly, receiving a message 
from the host mailbox causes any messages placed in the host memory by host 
processes to be transferred to the NX 200 process. 

Apart from transferring data by means of messages, processes controlled by NX 
200 can also directly read and write the the host memory by means of NX 200 
calls. The contents of messages sent and received from the host is not 
interpreted by the NX 200, and is strictly a matter of protocol between the host 
and the user software. 

1.11.1. Ethernet Interface 

The Ethernet interface also appears as a special dedicated mailbox. An NX 200 
process sends a packet over the Ethernet by sending the packet's address in a 
message to the special mailbox. The packet is formatted according to Ethernet 
specifications. The preamble and CRC are generated by the hardware 
automatically and need not be supplied by the user. After the packet is 
transmitted a reply message is returned to a user-specified mailbox, returning 
the packet buffer. Similarly, packets are received from the Ethernet by sending 
an empty buffer's address in a message to the special mailbox. When the 
Ethernet controller receives a message, it is stored in the buffer and a reply 
message is returned to the user-specified mailbox. 

Packets arriving over the Ethernet are filtered based on the destination address. 
Only those packets whose destination address matches one of addresses 
specified by the user are received. The address filter is implemented in 
hardware, but for multicast addresses, it is not perfect. Therefore NX 200 
supplements the hardware filter with a somewhat slower software filter which 
completes the filtering of multicast addresses. 

The user specifies receive addresses by means of address slots. Each slot 
carries one destination address. The user can selectively enable/disable receive 
on address slots. One address slot is reserved for the physical address and one 
slot is reserved for the broadcast address. The remaining address slots contain 



1-10 



NX 200: Introduction 

multicast addresses only. The number of multicast address slots is defined by 
the configuration of the NX 200. 

The Ethernet controller can operate in one of several possible modes selectable 
by the user. Specifically, the user can disconnect the controller from the 
network, disable/enable the software multicast address filter, enable to receive 
all packets from the network (promiscuous mode), and reject/accept packets 
received with errors. 

The network management functions are supported by NX 200 by keeping a tally 
of various events such as the number of packets transmitted/received, packet 
errors etc. 

1.11.2. Ethernet Link Level Controller Mode 

If NX 200 is to be used in link level controller mode, then most of the description 
above of NX 200 can be disregarded. In this mode, the host does not download 
any code to the board. Instead, the host sends command requests to the board 
which drive the Ethernet interface described above. When a request completes, 
NX 200 returns a reply message. Transmit and receive commands can be 
pipelined - NX 200 uses 60 Kbytes of the dual-ported RAM for buffering 
packets. 

1.12. NOTATIONS AND CONVENTIONS 

The following subsections describe the notations and conventions adhered to 
throughout this manual. Any restrictions presented here are applicable to all 
situations unless otherwise specified. The contents of these subsections should 
be carefully read first since the constraints mentioned here will not always be 
repeated in following sections. 

1.12.1. Number Base 

All numbers in this manual are decimal unless postfixed with the letter H, in 
which case they are hexadecimal. 

1.12.2. Data Object Terminology 

The following terms are used to describe data objects of various sizes: 



byte: 


8 bits 


word: 


16 bits 


longword: 


32 bits 



1.12.3. Message Format Specification 

The NX 200 provides access to some hardware functions by means of 
request/reply message pairs. Message formats are specified both in figures and 
descriptive paragraphs. The figures show the order of data fields, field length, 
offset from the message beginning, and include a brief description of the field's 
purpose. Descriptive paragraphs, keyed to the order of fields in the message, 
provide all necessary details not supplied in the figures. 

One column in the message figures, labeled "Request," specifies what value, if 
any, the field should have in the request message. Another column, labeled 
"Reply," specifies what value, if any, the reply message returns. When some 
definite value is specified for a field in a request message, this value must be 
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used, or undefined effects may occur. If a field is designated as "undefined" 
then it can have any arbitrary value. In the reply message, a field designated as 
"preserved" will return the same value as was supplied in the original request 
message. Where more comment is required, the entry "see text," directs the 
reader to a paragraph labeled with the same index as the field. 

1.12.4. Procedural Specifications 

Where it is necessary to describe a procedure, this manual uses the C 
programming language. Where appropriate, the language has been adapted in 
the style of pseudo-code. Such departures from the formal specification of C 
are denoted by enclosure in right-angle brackets, as in this example: 

in it Jo xq () { 

for(i=0;KQLEN;if+) { 

toxq[i].link = -16-bit offset of next buffer address >; 
toxq[il.rsrvd = 0; 
toxq[i|.status = TOXINITSTAT; 
toxq(i]. length = TOXDATALEN; 
initialize any user-specified fields • ; 

I 

1.12.5. Bit Position and Value Specifications 

When any data object is described in terms of separate bit fields, the Least 
Significant Bit (LSB) is designated as bit and the Most Significant Bit (MSB) as 
bit n, where the object's size is n+1 bits. For instance, bit 7 is the MSB of an 
8-bit data object. 

For programming convenience, bit fields are often described in terms of their 
OR-maskable numeric value instead of their position, as described above. For 
instance, if the description of a request mask reads: 

01 write request bit. 

02 read request bit. 

then a write is specified by bit and a read by bit 1. The value 03 specifies 
both read and write. 

1.12.6. Data Storage Order 

Many applications of NX require the consideration of two different programming 
environments: that of software on the EXOS Intelligent Ethernet Controller 
itself, and that of software on a host computer which communicates with NX 
200. In either environment, it is crucial that user software store data objects 
which are known to NX 200 firmware in the order which NX 200 expects - and 
that the programmer understand how NX 200 stores data objects which are 
known to user software. 

In NX 200s own memory address space, NX always interprets data in the 
CPU's native order. This means that in any data object of more than one byte, 
the most significant byte is stored at the higher memory address. For instance, 



1-12 



NX 200: Introduction 

a memory dump of the 32-bit value 0103070FH stored at NX 200 memory 
address 1C83H would appear as follows: 

1C83: OF 
1C84:07 
1C85: 03 
1C86: 01 

NX 200 can interpret data either in the CPU's native order, or optionally in the 
host system CPU's native order. This is controlled by the host data order 
conversion option, described fully in the EXOS Intelligent Ethernet Controller 
Reference Manual. If the conversion option is not enabled, then any data 
objects in host memory which NX 200 interprets must appear in the CPU's 
native order. 

If the conversion option is enabled, then NX 200 will automatically translate 
between its native order and the host CPU's native order when it reads and 
writes data to and from the host's memory. It decides what conversions are 
necessary by examining a constant pattern in host memory at initialization time. 
Conversions work independently on three data types: byte strings, words, 
and longwords. 

Note that because NX 200 must know the data type to apply the appropriate 
conversion, the word and longword conversion are applied only to data objects 
which NX 200 itself interprets, such as configuration information or Ethernet 
Data Link protocol parameters. Other data objects, such as an Ethernet 
packet's data field, are subject only to the byte string conversion applied to any 
data transferred between host memory and NX 200 memory. 

1.13. INTEGRATION WITH 68000-BASED SYSTEMS 

The host data order conversion for the byte string data type is intended primarily 
to accomodate microcomputer designs using the 68000 microprocessor (such 
as those based on the Stanford University Network (SUN) workstation design.) 
One idiosyncrasy of such processor implementations is that they invert bit of 
the memory address when performing byte-wide memory operations on 
some systems. 

On the Multibus system, this has a more complex effect than a simple byte 
swap on a word data type. For example, a byte quantity written at logical 
address 0003H appears at physical address 0002H in Multibus memory. NX 
200 automatically compensates for this peculiarity when the host data order 
conversion option is enabled. It will invert bit of host memory addresses, if 
required, on all Multibus memory access operations. 

For VMEbus, the majority of 68000 microcomputers are fully compatible with the 
VMEbus host data order. Therefore, when the EXOS 202 intelligent Ethernet 
controller is used on such systems, there should be no need for compensation 
or conversion to the host data order. 

The EXOS 203 Q-bus board is designed to communicate with the DEC Series of 
processors, and as such, does not need specific host data order conversion to 
be Q-bus compatible. 

Although the majority of 68000 microcomputers are not UNIBUS compatible. 
The EXOS 204 UNIBUS board is designed with the capability to perform host 
data 
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order conversion, automatically compensating for the host's data order, when 
the host data order conversion option is enabled. 

1.14. DATA ALIGNMENT 

All data structures defined by NX 200 firmware are designed so that they can be 
efficiently supported by processors and high-level languages which require even 
alignment of word and longword data types. 

While NX 200 does not generally require even byte address alignment, this 
practice is still recommended, in order to obtain the optimum performance. 

In only one instance, does NX 200 require special data alignment; the 
configuration message (see Chapter 2.4) must begin on an even logical address 
in host memory. 

1.15. MEMORY ADDRESS FORMAT 

All memory addresses are 32-bit objects unless otherwise specified. They are 
stored in memory in the same order as the longword data type. When NX 200's 
host data order conversion option is enabled, it will apply the same conversions 
to addresses stored in shared memory. 

The interpretation of memory addresses by NX 200 depends on context. Any 
address which refers to a location in NX 200 memory, whether the address 
value itself is stored in NX 200 memory or in host memory, is always interpreted 
as a segmented address. This term refers to the CPU's native address format. 
A segmented address consists of a 16-bit segment base and a 16-bit offset 
address. At run time, the CPU forms a 20-bit absolute address by shifting the 
segment base left by four places (multiply by 16) and adding the offset to the 
result. Therefore a segmented address can access 1 Mbyte of memory. Figure 
1 -4 shows how a segmented address is mapped into the longword data type. 



BIT 3 2 10 

NUMBER 10987654321098765432109876543210 

i SEGMENT BASE | OFFSET ADDRESS 

-+- + -+-4-- + -+-+- + -H 1--+-+-+- + - + - + - + - + - + -+- + - + - + - + - + - + - + - + - + - + - + - 

Figure 1-4: Mapping of Segmented Address into Longword Data Type 



When a segmented address is stored in NX 200 memory, it appears in the 
following order: 

Byte 0: Offset, low order 
Byte 1 : Offset, high order 
Byte 2: Segment, low order 
Byte 3: Segment, high order 

Storage order in the host system memory should appear the same to the NX 
200 operating system, unless the host data order conversion option is enabled, 
in which case it should appear in the host CPU's native order for the longword 
data type. 
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The interpretation of addresses which refer to host system memory locations 
depends on the NX 200's host address mode option. For a complete 
explanation of host access and memory addressing see the applicable EXOS 
Intelligent Ethernet Controller Reference Manual. In segmented mode, they are 
interpreted in the same manner as addresses referring to NX 200 memory 
locations. This restricts access to a 1 Mbyte range of host system memory, 
from 00000H to OFFFFFH. In order to provide access to the full 16 Mbyte 
Multibus memory address space, the NX 200 also provides an absolute host 
address mode. An absolute address is a simple 24-bit physical memory 
address, mapped into the longword data type as shown in Figure 1 -5. 



BIT 3 2 10 

NUMBER 10987654321098765432109876543210 

- + - + -+- + - + - + - + - + - + -+- + - + - + - + -+- + -+-+-+- + - + -+-+- + - + -H h- +-+-+-+- 

I RESERVED | ABSOLUTE ADDRESS I 

Figure 1-5: Mapping of Absolute Address into Longword Data Type 



As shown in the figure, the most significant 8 bits are reserved, and should be 
set to 0. When an absolute address is stored in NX 200 memory, it appears in 
the following order: 

Byte 0: least significant byte 
Byte 1 : somewhat significant byte 
Byte 2: most significant byte 
Byte 3: reserved, must be 

Storage order in the host system memory should appear the same to NX 200 
unless the host data order conversion option is enabled, in which case it should 
appear in the host CPU's native order for the longword data type. 

VMEbus Memory Address Format 

For VMEbus compatibility, NX 200 requires that the addresses which refer to the 
host system memory locations be specified in absolute address mode. An 
absolute address is a simple 24-bit physical memory address, mapped into the 
longword data type as shown in Figure 1-6. As shown, the 6-bit VMEbus 
address modifier should be provided in bits 24 through 29. The address 
modifier must be specified whenever a host system address is passed 
to NX 200. 
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BIT 3 2 10 

NUMBER 10987654321098765432109876543210 

-H 1 1 1 1 1 1 I--H 1--4 I--H 1 1 1 1 1 1 1 1 1 1 1 1 H---I 1 1 H--I-- 

lO I ADDRESS I ABSOLUTE ADDRESS I 

I I MOD I F I ER | | 

- + - + - H 1 1 — -I 1 — H 1 1 1-- -•-- H (-- H 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 — 

Figurv 1-6: VMEbus Mapping of Absolute Address into Longword Data Type 



As shown in the figure, the most significant 2 bits should be set to 0. When a 
host memory address is stored in EXOS Intelligent Ethernet Controller memory, 
it appears in the following order: 

Byte (bits 0-7): least significant byte 

Byte 1 (bits 8-15): somewhat significant byte 
Byte 2 (bits 16-23): most significant byte 
Byte 3 (bits 24-31): VMEbus address-modifier (bits 24-29); 

(bits 30-31 are reserved and must be 0) 

Storage order in the host system memory should appear the same to the EXOS 
Intelligent Ethernet Controller unless the host data order conversion option is 
enabled, in which case it should appear in the host CPU's native order for the 
longword data type. 

1.16. SHARED BUS MEMORY ACCESS RESTRICTIONS 

It is the user's responsibility to ensure that a specified bus memory address 
exists in functional memory. If an invalid address is specified and the EXOS 
Intelligent Ethernet Controller attempts to access it, then, depending on whether 
or not the "time out" option has been jumper-selected or not, one of the two 
things can happen: 

If the time out option is not selected, then the EXOS Intelligent Ethernet 
Controller does not time out if no memory response is received on the 
bus. To aid diagnostics, three bus Status LEDs are provided. Their 
location is shown in the appropriate EXOS Intelligent Ethernet Controller 
Reference Manual. When the LED DS3 is lit, the EXOS Intelligent 
Ethernet Controller is accessing the bus. Thus if DS3 is constantly lit 
then most likely the EXOS Intelligent Ethernet Controller has been given 
a non-existent address and is stuck waiting for the response. 

If the time out option is selected, then after 30 milliseconds the EXOS 
Intelligent Ethernet Controller goes offline and the status LEDs flash the 
error code BA (Hex) at regular intervals. 

The EXOS Intelligent Ethernet Controller can access data structures anywhere 
in the 16 Mbyte bus memory space. It accesses this address space by 
dynamically mapping two consecutive 64-Kbyte windows of its own CPU's 
address space into bus memory. User software does not perform either the 
mapping or the data transfer; it simply gives addresses to NX 200 firmware, 
which effects the transfer. Data structures that straddle beyond the 64-Kbyte 
bound are automatically accessed via the second window without any 
remapping. 
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Chapter 2 

INITIALIZATION AND HOST INTERFACE 

FOR MULTIBUS SYSTEMS 



2.1. INTRODUCTION 



The EXOS 201 Intelligent Ethernet Controller is specifically designed for use in a 
Multibus system. This section contains information pertinent to the design of 
host-resident software, such as an I/O driver, which communicates through 
NX 200 with the EXOS 201 Intelligent Ethernet Controller installed in a 
Multibus-based system. 

Note that EXOS Intelligent Ethernet Controllers are available for use with 
different computer buses; such as, Multibus, Q-bus, UNIBUS, VMEbus, and PC 
Bus. In addition, the EXOS controllers can be ordered for proprietary buses. 
While logically the NX 200 operating system functions remain the same, the 
specific procedures for initialization vary for different EXOS board-to-host 
combinations. Because of this variance, refer to the host system documentation 
to confirm the appropriate bus-type. 

The host interface can be broken down into two aspects, the initialization 
procedure, and the communication method subsequently used. Initialization 
refers to the process which begins upon resetting the EXOS 201, and concludes 
either with entering the Link Level Controller mode, or with the execution of 
downloaded software. During the process of initialization, the host system sets 
up the host message queue data structures. The host message queue protocol, 
defined by NX 200 firmware, uses these queues for all further communications 
between the host processor and NX 200. 

The following paragraphs give an overview of the Multibus initialization process: 

1. The host system resets the EXOS 201, then NX 200 executes 
self-diagnostics which exercise various board components and 
functions. If the diagnostics fail, then the EXOS Multibus board 
displays an error code on the NX 200 status LED (see Appendix A, 
Self-Diagnostic and Configuration Errors) until the board is reset 
again. If the diagnostics pass, then NX 200 awaits configuration by 
the host. 

2. The host system passes NX 200 the address of a configuration 
message in host memory. NX 200 examines this message, and 
modifies some fields according to the results of configuration. If 
configuration is unsuccessful, the EXOS 201 displays an error code 
on the NX 200 status LED until reset. If the configuration message 
is valid, then the EXOS 201 enters one of three modes, as 
specified by the operation mode field in the message. 

3. Initialization for each of the three different modes proceeds 
as follows: 

a. In Link Level Controller Mode, the EXOS 201 begins to execute 
firmware which brings NX 200's Ethernet Data Link driver 
interface out to the host system interface. No software is 
downloaded to the EXOS 201; instead the host system passes 
Data Link commands to the board and receives replies through 
the standard host message queue protocol. This mode is 
described fully in Section 6. 
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b. In Front-End Mode 1, the host system proceeds to download 
software to the EXOS201, by passing download request 
messages through the standard host message queue protocol. 
After the software has been downloaded, it passes an execute 
request to the board, which then begins to execute the 
downloaded software. Subsequent actions depend entirely on 
the software which has been downloaded, although the host 
message queue protocol remains in place. 

c. In Front-End Mode 2, the EXOS 201 proceeds to bootstrap 
itself from the Ethernet interface, as described in Section 1 1 . 
Depending on how the bootstrap server configures NX 200, it 
may still communicate with the host system through the 
standard host message queue protocol. Network bootstrap is 
quite similar in many ways to initialization by a host processor; 
the configuration message described in this section 
is identical. 

2.2. HARDWARE COMMUNICATIONS CHANNELS 

Communication between the host processor and the EXOS 201 is conducted via 
a coordinated exchange of interrupts, I/O instructions, and data transfers 
through shared memory on the Multibus. The following sections define these 
primitive channels of communication. These channels are used during the 
process of initialization and, subsequently, to implement the message 
queue protocol. 

2.2.1. Host Access to the EXOS 201 Multibus Board 

The host's means of active access to the EXOS 201 are solely through two I/O 
ports, named port A and port B here for the sake of reference. These ports are 
accessed over the Multibus, and can be both read and written. Their addresses 
are selected by jumpers on the EXOS 201 , as described in the EXOS 201 
Intelligent Ethernet Controller Reference Manual. 

The effects of reading and writing ports A and B in a Multibus system are 
summarized below: 

Read A: Resets the EXOS 201 (refer to Section 2.4). 

Write A: Causes NX 200 to drop the interrupt line, when it has asserted a 
non bus-vectored interrupt on the Multibus. This also clears the 
interrupt bit in port B. The value written is arbitrary, and is not 
accessible to software on the EXOS 201. 

Read B: Returns the EXOS 201 status byte: 

Bit 0: (Error Bit) when 0, indicates a fatal error in EXOS 201. 

When the EXOS 201 is reset, this bit is 0, but will be 
set to 1 if the self test completes successfully. If this 
bit is not set within 3 seconds, then the EXOS 201 has 
failed the self -diagnostics. 

Bit 1: (Interrupt Bit) is set whenever the EXOS 201 asserts a 

Multibus level interrupt. This is useful when an 
interrupt line is shared and polling is required. 
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An I/O write to port A clears this bit. The interrupt bit is 
defined only when level interrupts are selected. 

Bit 2: Undefined. 

Bit 3: (Ready Bit) when 0, indicates that NX 200 is ready to 

accept a byte written into port B. When 1, NX 200 has 
not yet read the byte last written into port B. 

Bits 4,5: Undefined. 

Bit 6: (Loopback Test Bit) when 0, indicates loopback test 

passed. When 1, indicates loopback test failed, 
possibly due to faulty transceiver or faulty transceiver 
cable. 

Bit 7: Undefined. 

Write B: Interrupts the EXOS 201 CPU, and communicates a 1- 
byte value. This is the only way to communicate a 
value to the EXOS 201 other than through 
shared memory. 

2.2.2. EXOS 201 Multibus Board Access to the Host 

The EXOS 201 functions as a master on a Multibus system. It can access the 
full 16-Mbyte memory address space and 64K I/O address space, and interrupt 
the host processor. User software on the EXOS 201 does not directly control 
these resources. Instead, it calls NX 200's host interface driver, described in 
Section 9. 

In general, data is transferred between the host and the EXOS 201 via shared 
memory. Shared memory can be any portion of system memory accessible to 
both processors on the Multibus. The EXOS 201 's CPU performs the transfer 
by dynamically mapping part of its own address space into the Multibus memory 
address space, and executing a block transfer instruction. Note that the 
EXOS 201 's on-board memory cannot be shared; it is not directly accessible by 
the host processor. 

The EXOS 201 can interrupt the host either through I/O addresses, memory 
addresses, or the Multibus interrupt lines. The type which will be used is 
selected at initialization time. Memory and l/O-mapped interrupt addresses are 
configured by software; the interrupt line is selectable by means of a jumper 
option, described in the EXOS 201 Intelligent Ethernet Controller Reference 
Manual. Unless l/O-mapped interrupts are selected, the NX 200 firmware will not 
normally generate I/O operations on the Multibus. User software on the 
EXOS 201 can use I/O instructions to control other peripheral cards. 

2.3. HOST DATA ORDER CONVERSION OPTION 

The host data order conversion option determines whether NX 200 will interpret 
data read from host memory according to its own native ordering, or according 
to the host CPU's native ordering. This option is selected by a field in the 
configuration message (refer to Section 2.5.5). If enabled, then NX 200 inspects 
a known data pattern in the configuration message, written in the host CPU's 
native order. It determines what conversions are necessary to make this pattern 
appear in the order it expects, for several different data types: byte array, word 
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array, and longword. NX 200 will then apply the appropriate conversion to all 
data objects subsequently read from host memory. 

For the byte array data type, NX 200 knows how to convert data stored 
according to the SUN design's byte addressing idiosyncrasies. This means that 
it will invert the least significant address bit when addressing host system 
memory, to reverse the effects of common 68000 CPU board designs. For the 
word data type, NX 200 can swap bytes if necessary. For the longword data 
type, NX 200 can swap words, swap bytes, or both. Therefore I/O driver 
software for any reasonably normal host CPU can store data objects in its native 
order, and leave conversion up to NX 200. 

Naturally, NX 200 must know the type of a data object to apply the appropriate 
conversion. All data objects described in this section are known to NX 200, 
except for the actual contents of messages between the host and the 
EXOS201. NX 200 does apply the byte array conversion (if necessary) to 
message contents, and to all data transferred. How the contents of messages 
should be further interpreted is the function of user-level software running on the 
EXOS201. For instance, the firmware which drives the Link Level Controller 
Mode (refer to Section 6) runs at user level under NX 200, and converts word 
and longword data objects which are known to itself, but not to NX 200. NX 200 
assists this process by providing kernel calls (refer to Section 9.5) which convert 
word and longword data types as required by the host data order conversion 
option. 

Whether or not the host data order conversion option is enabled, the host 
system must still write the required data pattern in the configuration message. 
This pattern occupies 12 bytes of the 32-byte test pattern/memory map field 
(refer to Section 2.5.10). It should be initialized as shown in Figure 2-1. Note 
that while the relative position of subfields in the test pattern is specified, the 
order of bytes within those subfields is dependent on the host CPU architecture. 
Figure 2-2 shows how this pattern might be initialized in the C language, both 
statically and dynamically. 

Note that memory addresses, regardless of the host address mode, are stored 
and interpreted as the longword data type. For instance, the longword test 
pattern can also be regarded as a memory address in the host's native format 
for the absolute address 0103070FH (if absolute address mode is selected) or 
for segment 070FH, offset 0103H (if segmented mode is selected). 

If NX 200 cannot make any sense of the test pattern presented by the host, 
then initialization is aborted, and the appropriate error code displayed on the 
status LED. For error code value assignments, see Appendix A, Self-Diagnostic 
and Configuration Errors. 

2.4. RESET AND CONFIGURATION PROCEDURE 

This section describes initialization by a host system up to the completion of 
configuration. Figure 2-3 shows a typical procedure which implements as much. 

The EXOS 201 is reset by the Multibus INIT signal, or whenever port A is read 
from the Multibus. Host software should use the latter method to be sure. On 
reset of the EXOS 201, NX 200 performs a Series of self tests to confirm 
hardware integrity. While these tests run, the NX 200 status LED (see Appendix 
A, Self-Diagnostic and Configuration Errors) will remain lit constantly. 
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Figure 2-1 : Host Data Order Conversion Option Test Pattern 
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When the self-diagnostics complete successfully, the EXOS Multibus board sets 
the error bit in I/O port B and flashes the status LED at regular intervals. 

If the error bit is not set within 3 seconds of reset, the host may assume that 
self-diagnostics turned up a problem. In this case, the EXOS 201 repeatedly 
reports an error code through the NX 200 status LED (for error code values, see 
Appendix A, Self-Diagnostic and Configuration Errors The EXOS 201 will remain 
in this state until reset again. 

A jumper option, described in the EXOS 201 Intelligent Ethernet Controller 
Reference Manual, determines how initialization will proceed after reset and 
self-diagnostics. If the jumper selects network bootstrap, then the EXOS 201 
will attempt to download software over the Ethernet (refer to Section 11.7). 
Otherwise the EXOS 201 awaits configuration by the host processor. 

The host configures the EXOS 201 by passing it the address of a configuration 
message, located in shared memory. This message establishes various NX 200 
parameters and selects among several modes of operation. Parameters include 
memory allocation for NX 200 objects, the address of NX 200's movable data 
area in EXOS 201 memory, and the location of message queues in shared 
memory. 

Among the optional operation modes, the host can select network bootstrap. 
This will proceed as though the net boot jumper option had been installed, 
except that NX 200 will first note the contents of the host configuration 
message. Other configuration options include host data order conversion and 
the host address mode. 
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/" constants for test pattern * 
#define BYTEO 0x01 
#define BYTE1 0x03 
#define BYTE2 0x07 
#define BYTE3 OxOF 
#define WORDO 0x0103 
^define WORD1 0x070F 
#define DWORD 0x0103070F 

/* static initialization of test pattern 
struct tstptrn j 

char byteptrn[4J; 

short wordptrn[2]; 

long Iwordptm; 

char rsrvd[20]; 



struct tstptrn tp = ( 

BYTEO. BYTE1 . BYTE2, BYTEE3, 
WORDO, W0RD1, 
DWORD. 
0,0,0,0,0,0,0,0,0,0.0,0,0.0,0,0,0,0.0,0 



/" dynamic initialization of test pattern V 

initptrn () 

I 

register int i; 

tp.byteptrn[0] = BYTEO: 

tp.byteptrn[1) = BYTE1; 

tp.byteptrn[2| = BYTE2; 

tp.byteptrn[3J = BYTE3; 

tp.wordptrn[OJ = WORDO; 

tp.wordptrn[1] = WORD1 ; 

tp.lwordptrn = DWORD; 

for (i==0: i<20; i++) tp.rsrvd[i] = 



Figure 2-2: Host Data Format Test Pattern Initialization 



The host processor communicates the address of the configuration message to 
the EXOS 201 by writing a sequence of 8 bytes into port B. Each byte should 
be written after checking to confirm the ready bit of the EXOS 201 s port B 
is clear. 

This ensures NX 200 is ready to accept the next address byte. The first four 
bytes of the sequence must be FF-FF-00-00 (sent from left to right). The next 
four bytes are the configuration message's absolute Multibus memory address 
(least significant byte first). The configuration message must be aligned on a 
even address boundary. When the last byte is written, NX 200 reads and 
interprets the configuration message. 

If the address for the initialization message is not valid, then NX 200 will display 
an error code on the status LED (see Appendix A, Self-Diagnostic and 
Configuration Errors 

When NX 200 has finished processing the configuration message, it writes a 
completion code into the appropriate field of the message. Any value other than 
0FFH indicates completion; the value indicates successful configuration. 
Other values denote specific errors in configuration (refer to Section 2.5.3). 
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extern read_port(Port_Num) /* returns value read from port PorLNum 7 
extern write_port(Port_Num, Val) /* writes Val to port PorLNum V 
extern start_clock() /* starts an interval timer 7 
extern clock() /* returns the current value of the interval timer 7 

/" bit value definitions for status byte read from port B 7 
#define ERROR_BIT 1 
#define READY_BIT8 
#define ERRNON 

struct { /* configuration message 7 

short reserved; 

char version[4]; 

char comp^code; 
<etc...> 
) initjnsg; 

char init_addrs[8) = {OxFF, OxFF, 0, 0, obsolute address of init msg> 
/* refer to Section 1 for absolute address format 7 

initialize () { 

< set up init_msg and the message queues (refer to Section 2.6) >; 

write-port(A); /* reset the EXOS 201 7 

start_clock(); /* start timer, clock counts real time 7 

/* wait until self test completes */ 
while ((read_port(B) & ERROR_BIT) = = ) { 
if (clock() > 2_SECONDS) ( 
return (malfunctioning_board); 



/* write the configuration message address 7 
for (i=0; i<8; i++) { 

while (read_port(B) & READY_BIT); 

write j>ort(B,init_addrs[i]); 
I 

/* wait for the reply message 7 

while (init_msg.comp_code == OxFF); 

/* ensure no errors 7 

if (init_msg,comp_code != ERRNON) 

return (error); 
else 

return (success); 



Figure 2-3: Typical Reset and Configuration Procedure 



Normally, configuration should complete within 3 seconds, but network bootstrap 
might take longer, depending on circumstances. NX 200 also returns a few 
parameters to the host in the configuration message, notably its version number 
and a map of available memory. 

Once configuration is complete, the memory space occupied by the 
configuration message can be used for any other purpose. After configuration, 
communication between the host and NX 200 is carried out solely by means of 
message queues, described in Section 2.5. 
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2.5. CONFIGURATION MESSAGE FORMAT 

Figure 2-4 shows the format of the configuration request/reply message. This is 
used identically by either a host system or a network bootstrap server. The 
following paragraphs explain the individual fields in detail. Note that reply values 
other than the completion code field itself are defined only if configuration 
is successful. 

2.5.1. Reserved Field 

The first field is reserved for use by NX 200. Its value in the request message 
must be 1 , and its return value is undefined. 

2.5.2. EXOS Version Code Field 

The EXOS version code field is undefined in the request message. In the reply 
message, it returns version codes for NX 200 and the EXOS 201 in the form 
X.Y and A.B, respectively. These are expressed as ASCII digits, one per byte 
in the order X-Y-A-B, starting from the lower address. 

2.5.3. Configuration Completion Code Field 

The completion code field must be 0FFH in the request message. The 
EXOS 201 signals that configuration is complete, and returns the completion 
code, by writing one of the following codes into this field: 

00H Successful completion. 

A4H Invalid operation mode. 

A5H invalid host data format test pattern. This occurs when NX 200 
cannot find any reasonable conversion to derive the expected 
data pattern from that supplied in the test pattern. In practice, 
this might imply that the host has given NX 200 the wrong 
address for the configuration message. 

A7H Invalid configuration message format. This may occur if 
reserved fields contain an improper value. In practice, this error 
message may indicate that the host has given NX 200 the 
wrong address for the configuration message. 

A8H Invalid movable block address. 

A9H Invalid number of processes. 

AAH Invalid number of mailboxes. 

ABH Invalid number of address slots. 

ACH Invalid number of hosts. 

ADH Invalid host message queue parameter. NX 200 returns this 
error if it detects any inconsistency in the message queue 
specifications. This might include a bad interrupt type, invalid 
segment address, bad linking of the message queue buffers, or 
similar conditions. 
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Figure 2-4a: Configuration Request/Reply Message (continued) 



AEH Insufficient memory for movable data block. 

AFH Net boot failed. 

The codes defined above will also be displayed on the status LED if 
configuration is not successful. 
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2.5.4. NX 200 Operation Mode Field 

The NX 200 operation mode field determines the mode in which the EXOS 201 
is to be used. Three different modes are supported: 

Link Level Controller Mode. This mode brings the Ethernet Data 
Link interface out to the host interface. No software is 
downloaded. It would typically be used when the EXOS 201 is 
substituted for the traditional non-programmable Ethernet 
controller board. For details, refer to Section 6. 

1 Front-End Mode, download from the host. In this mode the 
EXOS 201 is used as a front-end processor. Higher level 
software is downloaded by the host. 

2 Front-End Mode, download from the net. In this mode NX 200 
is used as a front-end processor and higher level software is 
downloaded from the network. For details, refer to 
Section 1 1 . 

All other values for the mode are reserved' and their effects are not defined. If 
NX 200 is already in the process of network bootstrap (meaning that the 
configuration message has been received from a bootstrap server) then only 
mode 2 is permitted. 

2.5.5. Host Data Order Option Field 

The host data order option field enables the host data order conversion option 
(refer to Section 2.3). Because the byte order of the host CPU will not be 
known before initialization, this field is actually treated as two one-byte fields. 
The host should load the same value into each sub-field in the request 
message. This value is defined bitwise: 

Bit 0: Deduce Format Bit. If 0, NX 200 will apply the conversions 

currently in force. If the board has not been previously 
configured, then the default conversion will be in force, 
meaning that no format conversions are applied to data read 
from the host. If this bit is 1, then NX 200 examines a 
constant data pattern written by the host in the configuration 
message's test pattern/memory map field, and deduces what 
format conversion are necessary to interpret various data 
types stored in the host CPU's native format. 

Bits 1 -7: Reserved. These bits must be in the request message. 

When initialized, NX 200 examines this field first, and interprets all other fields in 
the configuration message accordingly. This field is undefined in the 
reply message. 

2.5.6. EXOS Context 

This 3-byte field returns the EXOS context information. In the request message 
the value of this field must be zero. In the reply message, the middle byte 
(offset 1 1 ) returns the context value; the other two bytes are undefined. For 
NX 200 the context value must be 01 . 
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2.5.7. Host Address Mode Field 

The host address mode field determines how NX 200 will interpret addresses 
which refer to objects in host memory. It is defined bitwise: 

Bit 0: Set Mode Bit. If 0, NX 200 will use the address mode 

currently in force. If the board has not been previously 
configured, then the default mode will be in force, meaning 
that NX 200 will interpret all addresses as 80186-style 
segmented addresses. If this bit is 1, then the next bit 
determines the new address mode. 

Bit 1 : Address Mode Bit. The value selects segmented address 

mode. The value 1 selects absolute address mode. 

Bits 2-7: Reserved. These bits must be zero in the request message. 

This field is undefined in the reply message. 

2.5.8. Reserved Field 

This field is reserved for future use. Its value in the request message must be 
0. Its value in the reply message is undefined. 

2.5.9. Memory Map Size Field 

The memory map size field must be in the request message. In the reply 
message, it returns the number of segments available in EXOS 201 memory for 
user software. This field contains a valid value only if the EXOS 201 is 
configured in mode 1 or mode 2. 

2.5.10. Test Pattern/Memory Map Field and Maximum Packet Size 

The test pattern/memory map field serves different purposes in the request and 
reply messages. In the request message, it must contain the test pattern 
described in Section 2.3, stored in the host CPU's native format. 

In the reply message, the test pattern/memory map field contains a map of 
memory available for user software on the EXOS 201. This map consists of up 
to 4 segment descriptors, where the actual number is indicated by the last field. 
Each segment descriptor specifies a memory segment in terms of the lowest 
address and the highest address included within the segment. Each address is 
four bytes long, in the segmented format. The lower bound is given first, then 
the upper bound. 

This field contains a valid value only if NX 200 is configured in mode 1 or mode 
2. If the optional 128K of RAM between 20000H and 3FFFFH is either absent 
or is malfunctioning, then the map will not contain this segment. 

The above feature is also available to customers using NX 200, Versions 5.3 or 
later, in link-level controller and download modes. The host software may load 
the word at offset 34 from the beginning of the configuration message with a 
maximum packet size, excluding the CRC field. If the specified size is greater 
than 1514 bytes, NX 200 allows larger packets to be transmitted and received 
over Ethernet. The maximum packet size for non-buffer-chaining is 3FFFH. 
This mode, however, should be used with caution, since it allows for violating 
Ethernet specifications. 
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2.5.11. NX 200 Movable Block Address Field 

The NX 200 movable block address field can be used to redefine the location of 
NX 200's movable data area, described in Section 7.3. If the EXOS 201 is 
configured in mode 0, this field must be 0FFFFH, 0FFFFH. In modes 1 or 2, the 
value 0FFFFH, 0FFFFH specifies that the default location be used. If a non- 
default address is specified, the segment base must be 0. The offset must 
place the entire block either between 200H and 3FFH, or between 1000H 
and 0FFFFH. 

In the reply message, this field returns the actual address of the NX 200 
movable data area. The reply value is not defined in mode 0. 

2.5.12. Number of Processes Field 

The number of processes field configures the maximum number of processes 
which NX 200 will support. If the EXOS 201 is configured in mode 0, this field 
must be 0FFH. In modes 1 or 2, the value 0FFH specifies that the current value 
be used. The default value, after reset, is 12. Optionally, a value between 1 
and 128 can be specified. In the reply message, this field returns the actual 
number of processes which NX 200 will support. The reply value is not defined 
in mode 0. 

2.5.13. Number of Mailboxes Field 

The number of mailboxes field configures the maximum number of mailboxes 
which NX 200 will support. Note that this number does not include system 
mailboxes. If the EXOS 201 is configured in mode 0, this field must be 0FFH. 
In modes 1 or 2, the value 0FFH specifies that the current value be used. The 
default value, after reset, is 16. Optionally, a value between 1 and 128 can be 
specified. In the reply message, this field returns the actual number of 
mailboxes which NX 200 will support. The reply value is not defined in mode 0. 

2.5.14. Number of Multicast Slots Field 

The number of multicast slots field configures the maximum number of multicast 
address slots which NX 200 will support. Note that this number does not include 
the physical, broadcast, universal, or null slots, which are permanently allocated. 
If the EXOS 201 is configured in mode 0, this field must be 0FFH. In modes 1 
or 2, the value 0FFH specifies that the current value be used. The default 
value, after reset, is 8. Optionally, a value between and 252 can be specified. 
In the reply message, this field returns the actual number of address slots which 
NX 200 will support. The reply value is not defined in mode 0. 

2.5.15. Number of Hosts Field 

The number of hosts field specifies the number of host CPUs on the Multibus 
interface. Permissible values depend on the mode of operation. In all modes, 
the value 0FFH will retain the value currently in force. Upon first configuration, 
the default value is 0. In operation modes and 1, only the value 1 may be 
specified. However in mode 2 (network bootstrap), this field can be either or 
1. If 0, then the host message queues are undefined and the configuration 
message fields pertaining to them will not be examined. Its value is preserved 
in the reply message. 
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2.5.16. Host-to-EXOS Message Queue Base Address Field 

The host-to-EXOS message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from the host to the EXOS 201 (refer to Section 2.6). 
Addresses for all message queue data structures are 16-bit offsets, calculated 
relative to this base. NX 200s interpretation of this base address depends on 
the host address mode selected (see the EXOS 201 Intelligent Ethernet 
Controller Reference Manual. 

In segmented mode, this field must contain an 8086-style segmented address, 
stored according to the convention described for the longword data type (lower- 
order 16 bits contain the offset, higher-order 16 bits contain the segment). The 
offset value of this address must be 0; therefore the segment begins on some 
even 16-byte address boundary. Note that this format is sufficient only to 
describe a 20-bit address, or 1 Mbyte of host memory. 

In absolute mode this field contains a 24-bit absolute memory address, also 
stored as a longword. The lower-order 24 bits contain the address; the 
remaining high-order 8 bits are reserved and must be 0. Furthermore, the 
lower-order 4 bits of the address must also be 0, so that the segment begins on 
some even 16-byte address boundary. This format can describe 16 Mbytes of 
host memory. 

This field's value is preserved in the reply message. 

2.5.17. Host-to-EXOS Message Queue Header Address Field 

The host-to-EXOS message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the host-to-EXOS message queue. Its value in the reply message 
is preserved. 

2.5.18. Host-to-EXOS Message Queue Interrupt Type Field 

The host-to-EXOS message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
Host-to-EXOS 201 message queue. Options are: 

No interrupt. The host polls the message queues. 

1 I/O mapped. NX 200 writes a specified value at the specified 
I/O port address. 

2 Memory mapped. NX 200 writes a specified value at the 
specified memory address. 

3 Level interrupt. NX 200 raises one of the Multibus interrupt 
lines. The line is selectable by jumpers described in the EXOS 
201 Intelligent Ethernet Controller Reference Manual. Note that 
the interrupt remains asserted until the host explicitly clears it, 
by writing to the EXOS 201 's port A (refer to Section 2.6). 

If interrupt type 3 is selected, then NX 200 will set the interrupt bit, readable 
from port B, whenever it asserts a level interrupt. This bit is not defined when 
other interrupt types are selected. The value of this field is preserved in the 
reply message. 
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2.5.19. Host-to-EXOS Message Queue Interrupt Value Field 

The host-to-EXOS message queue interrupt value field is defined only for I/O 
mapped or memory mapped interrupt types. If these interrupt types are 
selected, then this value will be written to the specified I/O port or memory 
address when an interrupt is asserted. The value of this field is preserved in the 
reply message. 

2.5.20. Host-to-EXOS Message Queue Interrupt Address Field 

The host-to-EXOS message queue interrupt address field is defined only for I/O 
mapped or memory mapped interrupt types. If interrupt type 1 is selected, then 
it contains an 8 or 16-bit Multibus I/O port address in the first word, and the 
remaining word is undefined. If interrupt type 2 is selected, then this field 
contains a Multibus memory address, which NX 200 will interpret according to 
the host address mode. The value of this field is preserved in the 
reply message. 

2.5.21 . EXOS-to-Host Message Queue Base Address Field 

The EXOS-to-host message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from the EXOS 201 to the host (refer to Section 2.6). 
This is exactly equivalent to the host-to-EXOS message queue base address 
field (refer to Section 2.5.16). Its value in the reply message is preserved. 

2.5.22. EXOS-to-Host Message Queue Header Address Field 

The EXOS-to-host message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the EXOS-to-host message queue. Its value in the reply message 
is preserved. 

2.5.23. EXOS-to-Host Message Queue Interrupt Type Field 

The EXOS-to-host message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of 
EXOS 201-to-host message queue. Options are: 

No interrupt. The host polls the message queues. 

1 I/O mapped. NX 200 writes a specified value at the specified 
I/O port address. 

2 Memory mapped. NX 200 writes a specified value at the 
specified memory address. 

3 Level interrupt. NX 200 raises one of the Multibus interrupts 
lines. The line is selectable by jumpers described in the EXOS 
201 Intelligent Ethernet Controller Reference Manual. Note that 
the interrupt remains asserted until the host explicitly clears it, 
by writing to the EXOS 201 s port A (refer to Section 2.2). 

If interrupt type 3 is selected, then NX 200 will set the interrupt bit, readable 
from port B, whenever it asserts a level interrupt. This bit is not defined when 
other interrupt types are selected. The value of this field is preserved in the 
reply message. 
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2.5.24. EXOS-to-Host Message Queue Interrupt Value Field 

The EXOS-to-host message queue interrupt value field is defined only for I/O 
mapped or memory mapped interrupt types. If these interrupt types are 
selected, then this value will be written to the specified I/O port or memory 
address when an interrupt is asserted. The value of this field is preserved in the 
reply message. 

2.5.25. EXOS-to-Host Message Queue Interrupt Address Field 

The EXOS-to-host message queue interrupt address field is defined only for I/O 
mapped or memory mapped interrupt types. If interrupt type 1 is selected, then 
it contains an 8 or 16-bit Multibus I/O port address in the first word, and the 
remaining word is undefined. If interrupt type 2 is selected, then it contains a 
Multibus memory address, which NX 200 will interpret according to the host 
address mode. The value of this field is preserved in the reply message. 

2.6. MESSAGE QUEUE FORMAT 

Once the EXOS 201 is configured, message queues in shared memory serve all 
further communications with the host. This includes software down-load, link 
level controller mode service requests, and communication with downloaded 
protocol code. Two message queues are maintained by the NX 200 firmware, 
one for each direction of transfer. This section describes the format of the data 
structures which compose a message queue. Following sections describe how 
these must be initialized, and then the protocol which ensues after configuration. 
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Figure 2-5: Message Buffer Format 



Each message queue necessarily includes one queue header and a singly- 
linked, circular list of message buffers. The required queue header belongs to 
the EXOS 201 ; it reads and modifies its value during message exchange. The 
host may read it, but must not modify it. The EXOS 201 queue header and all 
message buffers must lie within a single 64K area of memory, called the 
queue segment. 
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Message queue data structures are described here as viewed by NX 200. The 
configuration message provides NX 200 with the queue segment base and the 
offset address of the queue header, for each queue. NX 200 regards the queue 
header value and link field values as 16-bit offsets calculated relative to the 
queue segment base. As long as this view is preserved for NX 200, users are 
perfectly free to augment these data structures in any manner necessary to 
implement the desired mechanisms for the host message handling software. 

Figure 2-5 shows the format of a message buffer, and the following paragraphs 
describe the individual fields in detail. 

2.6.1. Link Field 

The link field contains the address of the next buffer in the circular queue. This 
address must be an offset calculated relative to the queue segment base 
specified in the configuration message. This field is static and should not be 
changed after configuration. 

2.6.2. Reserved Field 

This field is reserved. It must be initialized with the value 0, and set to in 
Host-to-EXOS messages. Its value in reply message is undefined. 

2.6.3. Status Field 

The status field is used to implement the message protocol, and is defined bit 
by bit: 

Bit 0: Owner bit. If then the buffer is owned by the host; if 1 then 

the buffer is owned by NX 200. The host may alter a 
message buffer only while it has ownership. 

Bit 1: Done bit. The EXOS 201 sets this to along with the owner 

bit every time it passes a buffer to the host. Host software 
can use the done bit to distinguish between buffers newly 
received from NX 200 and buffers it has already processed. 

Bit 2: Overflow Bit. The EXOS 201 sets this bit to 1 if an EXOS- 

to-Host message had to be truncated because the host 
buffer's data field was shorter than the 
message sent. 

Bits 3-7: Undefined. These bits are reserved for NX 2Q0, and should 
not be used for any purpose by the host. 

2.6.4. Length Field 

The length field specifies the number of bytes in the data field. The maximum 
length of the data field is a matter of agreement between the host and the user 
software on the EXOS 201. There is no restriction on the size of the data field 
as long as the buffers satisfy the queue segment constraints. Most applications 
will transfer small amounts of control information via messages, and use direct 
memory access to move larger data buffers. 

In Host-to-EXOS messages, set this field's value before passing the message to 
the EXOS. In EXOS-to-Host messages, this field tells the host how many bytes 
were written after a message is transferred. The host must reset its value to the 
data field's size before returning a buffer to NX 200. 
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2.6.5. Data Field 

The data field contains the actual message data passed between the host and 
NX 200. NX 200 does not interpret its contents in any way - it is exactly 
equivalent to the data field in messages as seen by processes on the EXOS 201 
(refer to Section 7). However, if the host data order conversion option is 
enabled, and SUN-style address bit inversion is required, this conversion will be 
applied to the contents of the data field. 

2.7. MESSAGE QUEUE INITIALIZATION 

The host must initialize the message queues and the queue headers prior to 
configuring the EXOS 201. Figure 2-6 shows the relation between queue 
headers and message queue buffers at initialization time for a typical 
implementation. In each queue, the host and NX 200 queue headers should 
point to the same buffer. 
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Figure 2-6: Message Queue Data Structures at Initialization Time 



For each queue, the link fields should be initialized to form a circular, singly- 
linked list. This ring structure should not be modified after configuration. Each 
queue may contain an arbitrary number of buffers, so long as at least one is 
supplied. The reserved field of all message buffers in both queues should be 
set to 0. 

In the host-to-EXOS queue the status field of all buffers should contain the value 
02H, which indicates that they are owned by the host. The length and data 
fields are not defined at initialization. 
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In the EXOS-to-host queue the status field of all buffers should contain the value 
03H, which indicates that they are owned by NX 200. The length field of each 
buffer should not exceed the size of the data buffer. Note that the length field 
must be initialized to accommodate the length of the largest message expected 
from NX 200, or the message will be truncated upon reception. The data field is 
not defined at initialization. 

Figure 2-7 is a snapshot of an example EXOS-to-host message buffer queue at 
the time of initialization. This example assumes an 8086-based host system, 
where the EXOS 201 is configured in the segmented host address mode. The 
configuration message describing the queue is also shown in part. Data 
structures are shown as vectors containing hexadecimal byte values. The 
Multibus physical address of each data structure is shown to the left (slightly 
above the location), and its name to the right. According to the configuration 
message in this example, writing the value 40H at memory location 0E2044H 
will interrupt the host. NX 200 will assert this interrupt when the status of the 
EXOS-to-host message queue changes, as described in the following section. 
The circular message queue shown here contains three buffers of equal length, 
each providing a 32-byte data field. The queue header points to one of the 
buffers, arbitrarily chosen, at its link field address. 

2.8. MESSAGE QUEUE PROTOCOL 

This section describes the protocol which NX 200 follows in sending messages 
to, and receiving messages from, the host processor. As it happens, host 
software can follow the same procedure, so that the exchange is symmetrically 
defined. The description below assumes such an implementation, but certainly 
other methods are possible, within the constraints of NX 200's behavior. 

In a typical implementation, the host system and NX 200 each maintain private 
queue headers for both queues (see Figure 2-6). NX 200's host-to-EXOS 
message queue's header points to the message buffer which NX 200 will 
receive next. NX 200's EXOS-to-host message queue's header points to the 
message buffer which NX 200 will send to next. NX 200 maintains these queue 
headers after configuration. Although NX 200 queue headers are kept in host 
memory, after initialization the host should not refer to these. Similarly, the 
NX 200 will not refer to the host's own queue headers. Host queue headers 
may be of any format which is most convenient to the host software (16-bit 
offset, 32-bit virtual address, array index, etc.). 

For the host-to-EXOS queue, the host's queue header should always point to 
the next buffer in which the host will send a message. NX 200's queue header 
will always point to the next buffer in which NX 200 will look for a message. 
Both pointers will always move sequentially through the message queue. Note 
that unless a message arrives on the next buffer, NX 200 will not scan any 
further in the queue. This means that the host should always write the message 
in the next buffer where NX 200 expects it to be rather than in any arbitrary 
position in the queue. During the course of message processing, the host's 
queue header may end up several buffers ahead of NX 200's queue header, but 
should never "lap" it from behind. Any difference between the headers 
represents buffers which NX 200 has not yet consumed. 

For the EXOS-to-host queue, the host's queue header should always point to 
the next buffer in which the host will look for a message. The NX 200's queue 
header will always point to the next buffer in which NX 200 will send a message. 
As above, both pointers will always move sequentially through the message 
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queue. Note that unless a message arrives on the next buffer, the host should 
not scan any further in the queue. This means that NX 200 will always write the 
message in the next buffer where the host expects it to be rather than in any 
arbitrary position in the queue. During the course of message processing, 
NX 200's queue header may end up several buffers ahead of the host's queue 
header, but again, should never "lap" it from behind. Any difference between 
the headers represents buffers which the host has not yet consumed. 

2.8.1. Host-to-EXOS Message Transfer 

Host software can use the following sequence of steps to transfer messages to 
NX 200: 

1. Test the owner bit of the buffer to which the host queue header 
points. If NX 200 still owns this buffer, then wait until it is returned 
(either poll the owner bit, or wait for the interrupt which 
accompanies each buffer turnover event). 

2. Advance the host queue header, so that it now points to the next 
buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field appropriately. 

4. Set the current buffer's owner bit, so that the buffer now belongs to 
NX 200. 

15. Interrupt NX 200 by writing to port B, to notify it that a new 
message is available. 

The EXOS 201 can process more than one message from the host upon 
receiving a single interrupt. Therefore it is important that the host change the 
buffer's owner bit only after preparing the other fields. Otherwise, if NX 200 is 
still processing a previous interrupt from the host, it may consume a half-baked 
message. Note that the host may prepare more than one message buffer at a 
time, and send a single interrupt, if sufficient buffers are available. 

When NX 200 receives an interrupt from the.host, it will: 

1 . Examine the owner bit of the buffer to which its own queue header 
points. If the buffer belongs to NX 200, then it will process it, as 
described in the following steps. (Otherwise, the interrupt could 
mean that the host is returning an EXOS-to-host message buffer, or 
could be spurious.) 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Extract the message from the current buffer. If there is no 
consumer for this data (no receive request on the NX 200s host 
interface mailbox), then wait. 

4. Reset the current buffer's owner bit, so that the buffer is returned to 
the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a buffer has been returned. The 
type of interrupt is specified by the configuration message. Repeat 
from step 1, until the owner bit shows that no new messages 
are pending. 
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Figure 2-7: Example EXOS-to-Host Message Queue, at Initialization 
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Note that the interrupt described in step 5 is the same interrupt which the host 
waits upon when no message buffers are available. 

2.8.2. EXOS-to-Host Message Transfer 

When NX 200 has a message to transfer to the host, it will: 

1 . Test the owner bit of the buffer to which its queue header points. If 
the buffer belongs to NX 200, then process it, as described in the 
following steps. Otherwise, wait for an interrupt from the host which 
indicates that a buffer has been returned (NX 200 can process 
other jobs in the mean time). 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field to the length actually transferred (it will not exceed 
data field length). If the data field was too short for the entire 
message, then it sets the overflow bit. 

4. Reset the current buffer's owner bit, so that the buffer now belongs 
to the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a new message is available. The 
type of interrupt is specified by the configuration message. 

When the host receives an interrupt from NX 200, it can: 

1 . Examine the owner bit of the buffer to which the host queue header 
points. If the buffer belongs to the host, then it should process it, 
as described in the following steps. (Otherwise, the interrupt could 
mean that NX 200 is returning a host-to-EXOS message buffer, or 
could be spurious.) 

2. Advance the host's own queue header, so that it now points to the 
next buffer in the queue. 

3. Extract the message from the current buffer. It may check the 
overflow bit to be certain that the entire message was sent. If there 
is no consumer for this data, then wait. 

4. Set the length field to the size of the data field. 

5. Set the current buffer's owner bit, so that the buffer is returned to 
NX 200. 

6. Interrupt NX 200 by writing to port B, to notify it that a message 
buffer has been returned. Repeat from step 1, until the owner bit 
shows that no new messages are pending. 

Note that whenever the host receives a non bus-vectored interrupt from NX 200, 
it should write to the EXOS 201 s port A before processing any message queue 
events. This causes NX 200 to drop its interrupt line, permitting the host to 
recognize another interrupt. During the host's interrupt service routine, it is 
assumed that further interrupts from NX 200 are disabled, but that the host's 
interrupt controller will still buffer one interrupt from NX 200 until leaving the 
service routine and re-enabling interrupts at that level. 
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NX 200 will assert an interrupt whether or not the host has cleared its interrupt 
line - therefore interrupts may merge together, so far as the host can tell. This 
is why the host should be prepared, whenever it receives an interrupt, to 
process multiple messages and/or buffers returned by NX 200. Furthermore, 
the host should be prepared to receive a spurious interrupt from NX 200. 

Although the above description assumes that the EXOS 201 is programmed to 
interrupt the host to signal message queue events, the host also has the option 
of simply polling the message queue. 

2.9. DOWNLOADING SOFTWARE FROM THE HOST 

Normally, if the EXOS 201 is configured in mode 1 , host software would then 
download and run higher level protocol software. Two message formats are 
provided for this purpose, one to copy user code and data to NX 200, and 
another to start code execution. For each message NX 200 sends a 
corresponding reply message which confirms the completion of the request. 

2.9.1. Host Download Request 

The host can copy code to any location in NX 200 memory which is normally 
available to the user. The download request copies buffers up to 64K-1 each in 
size, in any order, without modification. NX 200 does not protect the user area 
against un-intentional overlays. 

Figure 2-8 shows the format of the download request/reply message, and the 
following paragraphs describe the individual fields in detail. 

2.9.1.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 

2.9.1.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

2.9.1.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 0. This value is preserved in the reply message. 

2.9.1.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the download request: 

successful completion. 

A3H destination memory block overlaps the memory reserved for 
NX 200, no copy done. 

A1H invalid request, the EXOS 201 is not in front end mode. 
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Figure 2-8: EXOS 201 Down-Load Request/Reply Message 
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2.9.1.5. Data Length Field 

The data length field specifies the number of bytes to be copied into NX 200 
memory. This may be any value between and 64K-1. In the reply message, 
this field returns the number of bytes actually copied. 

2.9.1.6. Source Address Field 

The source address field specifies the starting address in shared memory from 
which to copy the user code image. This may be either a segmented or an 
absolute address, depending on the host address mode option. Its value in the 
reply message is undefined. 

2.9.1.7. Destination Address Field 

The destination address field specifies the starting address in NX 200 memory 
to which the user code image will be copied. This must be a segmented 
address. Its value in the reply message is undefined. 
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2.9.2. Start Execution Request 

After downloading protocol software, the host processor starts it executing with 
a single start execution request message. Once this command has been issued 
and the reply received, NX 200 does not itself process any more messages. 
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Figure 2-9: NX 200 Start-Execution Request/Reply Message 
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Instead, all messages sent to NX 200 will be queued up for user processes 
running under the NX 200 kernel. 

The start execution request specifies the location at which execution of user 
code begins. User code is entered as a single process with priority 255 and 
infinite time slice. All registers except for the PC and stack pointer are 
undefined. The initial process stack is provided from the NX 200 data area and 
is guaranteed to be at least 100H bytes deep. The process is free to switch to a 
bigger stack if desired. In all other respects, it is a normal process, as defined 
in Section 7.5. 

Figure 2-9 shows the format of the start execution request/reply message, and 
the following paragraphs describe the individual fields in detail. 

2.9.2.1. Reserved Field 

The first field is reserved for use by NX 200, and must be initialized as 0. Its 
value in the reply message is undefined. 
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2.9.2.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

2.9.2.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 2. This value is preserved in the reply message. 

2.9.2.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the start execution request. 

Successful completion. 

A2H Invalid starting address, execution not started. 

A1H Invalid request, the EXOS 201 is not in front end mode. 

2.9.2.5. Starting Address Field 

The starting address field specifies the initial value of the initial process's 
program counter. This must be a segmented address. Its value is preserved in 
the reply message. 
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Chapter 3 

INITIALIZATION AND HOST INTERFACE 

FOR VMEBUS SYSTEMS 



3.1. INTRODUCTION 



The EXOS 202 Intelligent Ethernet Controller is specifically designed for use in a 
VMEbus system. This section contains information pertinent to the design of 
host-resident software, such as an I/O driver, which communicates with the 
EXOS 202 Intelligent Ethernet Controller installed in a VMEbus-based system. 

Note that EXOS Intelligent Ethernet Controllers are available for use in different 
computer buses, such as, Multibus, Q-bus, UNIBUS, VMEbus, and PC bus. 
While logically the NX 200 operating system functions remain the same, the 
specific procedures for initialization vary for different EXOS board-to-host 
combinations. 

The host interface can be broken down into two aspects, the initialization 
procedure, and the communication method subsequently used. Initialization 
refers to the process which begins upon resetting the EXOS 202, and concludes 
either with entering the Link Level Controller mode, or with the execution of 
downloaded software. During the process of initialization, the host system sets 
up the host message queue data structures. The host message queue protocol, 
defined by NX 200 firmware, uses these queues for all further communications 
between the host processor and NX 200. 

The following paragraphs give an overview of the initialization process: 

1 . The host system resets the EXOS 202, then NX 200 executes 
self-diagnostics which exercise various board components and 
functions. If the diagnostics fail, the EXOS 202 displays an error 
code on the NX 200 status LED (see Appendix A) until reset again. 
If the diagnostics pass, the EXOS 202 awaits configuration by 
the host. 

2. The host system passes NX 200 the address of a configuration 
message in host memory. The EXOS 202 examines this message, 
and modifies some fields according to the results of configuration. 
If configuration is unsuccessful, the EXOS 202 again displays an 
error code on the NX 200 status LED until reset. If the 
configuration message is valid, then the EXOS 202 enters one of 
three modes, as specified by the message's operation mode field. 

3. Initialization for each of the three different modes proceeds as 
follows: 

a. In Link Level Controller Mode, the EXOS 202 begins to execute 
firmware which brings NX 200's Ethernet Data Link driver 
interface out to the host system interface. No software is 
downloaded; instead the host system passes Data Link 
commands to the board, and receives replies, through the 
standard host message queue protocol. This mode is 
described fully in Section 6. 

b. In Front-End Mode 1, the host system proceeds to download 
software to the EXOS 202, by passing download request 
messages through the standard host message queue protocol. 
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request to the board, which then begins to execute the 
downloaded software. Subsequent actions depend entirely on 
the software which has been installed, although the host 
message queue protocol remains in place. 

c. In Front-End Mode 2, the EXOS 202 proceeds to bootstrap 
itself from the Ethernet interface, as described in Section 11. 
Depending on how the bootstrap server configures NX 200, it 
may still communicate with the host system through the 
standard host message queue protocol. Network bootstrap is 
quite similar in many ways to initialization by a host processor; 
the configuration message described in this section is 
exactly identical. 



3.2. HARDWARE COMMUNICATIONS CHANNELS 

Communication between the host processor and the EXOS 202 is conducted via 
a coordinated exchange of interrupts, I/O instructions, and data transfers 
through shared memory on the VMEbus. The following sections define these 
primitive channels of communication which are used during the process of 
initialization and, subsequently, to implement the message queue protocol. 

3.2.1. Host Access to the EXOS 202 VMEbus Board 

The host's means of active access to the EXOS 202 are solely through two 
memory mapped I/O ports, named port A and port B here for the sake of 
reference. These ports are accessed over the VMEbus, and can be both read 
and written. Their addresses are selected by jumpers on the EXOS 202, 
described in the EXOS 202 Intelligent Ethernet Controller Reference Manual. 

The effects of reading and writing ports A and B are summarized below: 



Read A 
Write A 
Read B 



Write B: 



No Operation. 

Resets the EXOS 202 (refer to Section 3.4). 

Returns the EXOS 202 status byte: 

Bit 0: (Error Bit) when 0, indicates a fatal error in EXOS 202. 

When the EXOS 202 is reset, this bit is 0, but will be 
set to 1 if the self test completes successfully. If this 
bit is not set within 3 seconds, then the EXOS 202 has 
failed the self-diagnostics. 

Bits 1-2: Undefined. 

Bit 3: (Ready Bit) when 0, indicates that NX 200 is ready to 

accept a byte written into port B. When 1 , NX 200 has 
not yet read the byte last written into port B. 

Bits 4-7: Undefined. 

Interrupts the EXOS 202 CPU, and communicates a 1-byte value. 
This is the only way to communicate a value to the EXOS 202 
other than through shared memory. 
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3.2,2. EXOS 202 VMEbus Board Access to the Host 

The EXOS 202 functions as a master on a VMEbus system. It can access the 
full 16-Mbyte memory address space and interrupt the host processor. User 
software on the EXOS 202 does not directly control these resources. Instead, it 
calls NX 200's host interface driver, described in Section 9. 

In general, data is transferred between the host and the EXOS 202 via shared 
memory, which may be any portion of system memory accessible to both 
processors on the VMEbus. The EXOS 202's CPU performs the transfer by 
dynamically mapping part of its own address space into the VMEbus memory 
address space, and executing a block transfer instruction. Note that the 
EXOS 202's on-board memory cannot be shared; it is not directly accessible by 
the host processor. 

The EXOS 202 can interrupt the host either through memory addresses or the 
VMEbus interrupt lines. The type which will be used is selected at initialization 
time. Memory interrupt addresses are configured by software; the interrupt line 
is selectable by means of a jumper option, described in the EXOS 202 Intelligent 
Ethernet Controller Reference Manual. 

3.3. HOST DATA ORDER CONVERSION OPTION 

The host data order conversion option determines whether NX 200 will interpret 
data read from host memory according to its own native ordering, or according 
to the host CPU's native ordering. This option is selected by a field in the 
configuration message (refer to Section 3.5.5). If enabled, then the NX 200 
inspects a known data pattern in the configuration message, written in the host 
CPU's native order. It determines what conversions are necessary to make this 
pattern appear in the order it expects, for several different data types: byte 
array, word array, and longword. NX 200 will then apply the appropriate 
conversion to all data objects subsequently read from host memory. 

For the word data type, NX 200 can swap bytes if necessary. For the longword 
data type, NX 200 can swap words, swap bytes, or both. Therefore I/O driver 
software for any reasonably normal host CPU can store data objects in its native 
order, and leave conversion up to the EXOS 202. 

Naturally, the EXOS 202 must know the type of a data object to apply the 
appropriate conversion. All data objects described in this section are known to 
NX 200, except for the actual contents of messages between the host and the 
EXOS 202. NX 200 does apply the byte array conversion (if necessary) to 
message contents, and to all data transferred. How the contents of messages 
should be further interpreted is the function of user-level software running on the 
EXOS 202. For instance, the firmware which drives the Link Level Controller 
Mode (refer to Section 6) runs at user level under NX 200, and converts 
word/longword data objects which are known to itself, but not to NX 200. 

NX 200 assists this process by providing kernel calls (refer to Section 9.5) which 
convert word and longword data types as required by the host data order 
conversion option. 

Whether or not the host data order conversion option is enabled, the host 
system must still write the required data pattern in the configuration message. 
This pattern occupies 12 bytes of the 32-byte test pattern/memory map field 
(refer to Section 3.5.10). It should be initialized as shown in Figure 3-1. Note 
that while the relative position of subfields in the test pattern is specified, the 
order of bytes within those subfields is dependent on the host CPU architecture. 
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Figure 3-2 shows how this pattern might be initialized in the C language, both 
statically and dynamically. 

Note that memory addresses, regardless of the host address mode, are stored 
and interpreted as the longword data type. For instance, the longword test 
pattern can also be regarded as a memory address in the host's native format 
for the absolute address 0103070FH (if absolute address mode is selected) or 
for segment 070FH, offset 0103H (if segmented mode is selected). 

If NX 200 cannot make any sense of the test pattern presented by the host, 
then initialization is aborted, and the appropriate error code displayed on the 
status LED. For error code value assignments; see Appendix A: Self- 
Diagnostics and Configuration Errors. 
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Figure 3-1 : Host Data Order Conversion Option Test Pattern 



3.4. RESET AND CONFIGURATION PROCEDURE 

This section describes initialization by a host system up to the completion of 
configuration. Figure 3-3 shows a typical procedure which implements as much. 

The EXOS 202 is reset by the VMEbus SYSRESET signal, or whenever port A 
is written from the VMEbus. Host software should use the latter method to be 
sure. On reset of the EXOS 202, NX 200 performs a Series of self tests to 
confirm hardware integrity. While these tests run, the NX 200 status LED (see 
the EXOS 202 Intelligent Ethernet Controller Reference Manual) will remain lit 
constantly. When self-diagnostics complete successfully, the EXOS 202 sets 
the error bit in I/O port B and flashes the status LED at regular intervals. 
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If the error bit is not set within 3 seconds of reset, the host may assume that 
self-diagnostics turned up a problem. In this case, the EXOS 202 repeatedly 
reports an error code through the NX 200 status LED (for error code values, see 
Appendix A: Self-Diagnostics and Configuration Errors). The EXOS 202 will 
remain in this state until reset again. 

A jumper option, described in the EXOS 202 Intelligent Ethernet Controller 
Reference Manual, determines how initialization will proceed after reset and 
self-diagnostics. If the jumper selects network bootstrap, then the EXOS 202 
will attempt to download software over the Ethernet (refer to Section 11.7). 
Otherwise the EXOS 202 awaits configuration by the host processor. 



/* constants for test pattern */ 
#define BYTE0 0x01 
#define BYTE1 0x03 
#define BYTE2 0x07 
#define BYTE3 OxOF 
#define WORD0 0x0103 
#define WORD1 0x070F 
#define DWORD 0x01 03070F 

/* static initialization of test pattern */ 
struct tstptrn { 

char byteptrn[4); 

short wordptrn[2]; 

long Iwordptrn; 

char rsrvd[20]; 
}; 

struct tstptrn tp = { 

BYTE0, BYTE1, BYTE2, BYTE3, 
WORD0, WORD1 , 
DWORD, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 



/* dynamic initialization of test pattern */ 

initptrn () 

{ 

register int i; 

tp.byteptrn[0] = BYTEO; 

tp.byteptrn[1] = BYTE1; 

tp.byteptrn[2] = BYTE2; 

tp.byteptrn[3] = BYTE3; 

tp.wordptrn[0] = WORDO; 

tp.wordptrn[1) = WORD1; 

tp.lwordptrn = DWORD; 

for (i=0; i<20; l+ +) tp.rsrvd[i] = 0; 
} 

Figure 3-2: Host Data Format Test Pattern Initialization 



The host configures the EXOS 202 by passing it the address of a configuration 
message, located in shared memory. This message establishes various NX 200 
parameters and selects among several modes of operation. Parameters include 
memory allocation for NX 200 objects, the address of NX 200's movable data 
area in EXOS 202 memory, and the location of message queues in shared 
memory. Among the optional operation modes, the host can select network 
bootstrap. This will proceed as though the net boot jumper option had been 
installed, except that NX 200 will first note the contents of the host configuration 



3-5 



NX 200: Initialization and Host Interface for VMEbus Systems 

message. Other configuration options include host data order conversion and 
the host address mode. 



extern read_port(Port_Num) /* returns value read from port Port_Num 7 
extern write_port(Port_Num, Val) /* writes Val to port Port_Num */ 
extern start _clock() /* starts an interval timer */ 
extern clock() ,* returns the current value of the interval timer 7 

/' bit value definitions for status byte read from port B 7 
#define ERROR J5IT 1 
#define READY_BIT8 
#define ERRNON 

struct j i" configuration message 7 

short reserved; 

char version[4); 

char comp_code; 
-- etc> 
} init_msg: 

char init_addrs[8] = (OxFF, OxFF, 0, 0, obsolute address of init msg> ); 
/* refer to Section 1 for absolute address format 7 

initialize () { 

< set up init_msg and the message queues (refer to Section 3.6) >; 
write-port(A); /* reset the EXOS 202 7 
star_clock(), /"' start timer, clock counts real time 7 

/* wait until self test completes 7 
while ((read_port(B) & ERROR.BIT) = = ) { 
if (clOCk() > 2_SECONDS) { 
return (malfunctioning_board); 

} 



r write the configuration message address 
for(i=0; i<8; if +) i 

while (read j>ort(B) & READY.BIT); 

write_port(B,init_addrs[i]); 



/" wait for the reply message 7 

while (init_msg.comp_code = = OxFF); 

,'* ensure no errors */ 

if (init_msg.comp_.code != ERRNON) 

return (error); 
else 

return (success); 



Figure 3-3: Typical Reset and Configuration Procedure 



The host processor communicates the address of the configuration message to 
NX 200 by writing a sequence of 8 bytes into port B. Each byte should be 
written after checking that the ready bit of the EXOS 202's port B is clear. This 
ensures that the EXOS VMEbus board is ready to accept the next address byte. 
The first four bytes of the sequence must be FF-FF-00-00 (sent from left to 
right). The next four bytes are the configuration message's absolute VMEbus 
memory address (least significant byte first). Note that the VMEbus address 
modifier must be passed in the low-order 6 bits of the last byte passed to 
EXOS 202 and that the high order 2 bits of this byte must be zero. The 
configuration message must be aligned on a even address boundary. When the 
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last byte is written, NX 200 reads and interprets the configuration message. If 
the address for the initialization message is not valid, then NX 200 will display 
an error code on the status LED (see Appendix A; Self-Diagnostics and 
Configuration Errors) 

When NX 200 has finished processing the configuration message, it writes a 
completion code into the appropriate field of the message. Any value other than 
0FFH indicates completion. The value indicates successful configuration while 
other values denote specific errors in configuration (refer to Section 3.5.). 
Normally, configuration should complete within 3 seconds, but network bootstrap 
might take longer, depending on circumstance. NX 200 also returns a few 
parameters to the host in the configuration message, notably its version number 
and a map of available memory. 

Once configuration is complete, the memory space occupied by the 
configuration message can be used for any other purpose. After configuration, 
communication between the host and NX 200 is carried out solely by means of 
message queues, described in Section 3.5. 

3.5. CONFIGURATION MESSAGE FORMAT 

Figure 3-4 shows the format of the configuration request/reply message. This is 
used identically by either a host system or a network bootstrap server. The 
following paragraphs explain the individual fields in detail. Note that reply values 
other than the completion code field itself are defined only if configuration 
is successful. 

3.5.1. Reserved Field 

The first field is reserved for use by NX 200. Its value in the request message 
must be 1 , and its return value is undefined. 

3.5.2. EXOS Version Code Field 

The EXOS version code field is undefined in the request message. In the reply 
message, it returns version codes for NX 200 and the EXOS 202 in the form 
X.Y and A.B, respectively. These are expressed as ASCII digits, one per byte 
in the order X-Y-A-B, starting from the lower address. 

3.5.3. Configuration Completion Code Field 

The completion code field must be 0FFH in the request message. The 
EXOS 202 signals that configuration is complete, and returns the completion 
code, by writing one of the following codes into this field: 

00H successful completion. 

A4H invalid operation mode. 

A5H invalid host data format test pattern. This occurs when NX 200 
cannot find any reasonable conversion to derive the expected 
data pattern from that supplied in the test pattern. In practice, 
this might imply that the host has given NX 200 the wrong 
address for the configuration message. 
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A7H Invalid configuration message format. This may occur if reserved fields 
contain an improper value. In practice, this error message may indicate 
that the host has given NX 200 the wrong address for the configuration 
message. 

A8H Invalid movable block address. 

A9H Invalid number of processes. 

AAH Invalid number of mailboxes. 

ABH Invalid number of address slots. 

ACH Invalid number of hosts. 

ADH Invalid host message queue parameter. NX 200 returns this error if it 
detects any inconsistency in the message queue specifications. This 
might include a bad interrupt type, invalid segment address, bad linking 
of the message queue buffers, etc. 

AEH Insufficient memory for movable data block. 

AFH Net boot failed. 

The above codes will also be displayed on the status LED if configuration is not 
successful. 

3.5.4. NX 200 Operation Mode Field 

NX 200 operation mode field determines the mode in which the EXOS 202 is to 
be used. Three different modes are supported: 

Link Level Controller Mode. This mode brings the Ethernet Data 
Link interface out to the host interface. No software is 
downloaded. It would typically be used when the EXOS 202 is 
substituted for the traditional non-programmable Ethernet 
controller board. For details, refer to Section 6. 

1 Front-End Mode, download from the host. In this mode the 
EXOS 202 is used as a front-end processor. Higher level 
software is downloaded by the host. 

2 Front-End Mode, download from the net. In this mode the 
EXOS 202 is used as a front-end processor and higher level 
software is downloaded from the network. For details, refer to 
Section 1 1 . 

All other values for the mode are reserved and their effects are not defined. If 
NX 200 is already in the process of network bootstrap (meaning that the 
configuration message has been received from a bootstrap server) then only 
mode 2 is permitted. 

3.5.5. Host Data Order Option Field 

The host data order option field enables the host data order conversion option 
(refer to Section 3.3.). Because the byte order of the host CPU will not be 
known before initialization, this field is actually treated as two one-byte fields. 
The host should load the same value into each sub-field in the request 
message. This value is defined bitwise: 



3-10 



NX 200: Initialization and Host Interface for VMEbus Systems 

Bit 0: Deduce Format Bit. If 0, NX 200 will apply the conversions 

currently in force. If the board has not been previously 
configured, then the default conversion will be in force, 
meaning that no format conversions are applied to data read 
from the host. If this bit is 1 , then NX 200 examines a 
constant data pattern written by the host in the configuration 
message's test pattern/memory map field, and deduces what 
format conversion are necessary to interpret various data 
types stored in the host CPU's native format. 

Bits 1-7: Reserved. These bits must be in the request message. 

When initialized, NX 200 examines this field first, and interprets all other fields in 
the configuration message accordingly. This field is undefined in the 
reply message. 

3.5.6. EXOS Context 

This 3-byte field returns the EXOS context information. In the request message 
the value of this field must be zero. In the reply message, the middle byte 
(offset 1 1 ) returns the context value; the other two bytes are undefined. For the 
EXOS 202 the context value must be 02. 

3.5.7. Host Address Mode Field 

Each of the bits and 1 of this field must be set to 1 to indicate absolute 
address mode. The remaining bits are reserved and must be zero in the 
request message. 

This field is undefined in the reply message. 

3.5.8. Reserved Field 

This field is reserved for future use. Its value in the request message must be 
0. Its value in the reply message is undefined. 

3.5.9. Memory Map Size Field 

The memory map size field must be in the request message. In the reply 
message, it returns the number of segments available in EXOS 202 memory for 
user software. This field contains a valid value only if the EXOS 202 is 
configured in mode 1 or mode 2. 

3.5.10. Test Pattern/Memory Map Field and Maximum Packet Size 

The test pattern/memory map field serves different purposes in the request and 
reply messages. In the request message, it must contain the test pattern 
described in Section 3.3 stored in the host CPU's native format. 

In the reply message, the test pattern/memory map field contains a map of 
memory available for user software on the EXOS 202. This map consists of up 
to 4 segment descriptors, where the actual number is indicated by the last field. 
Each segment descriptor specifies a memory segment in terms of the lowest 
address and the highest address included within the segment. Each address is 
four bytes long, in the segmented format. The lower bound is given first, then 
the upper bound. This field contains a valid value only if the EXOS 202 is 
configured in mode 1 or mode 2. 
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3.5.11. NX 200 Movable Block Address Field 

The NX 200 movable block address field can be used to redefine the location of 
NX 200's movable data area, described in Section 7.3. If the EXOS 202 is 
configured in mode 0, this field must be 0FFFFH, 0FFFFH. In modes 1 or 2, the 
value 0FFFFH, 0FFFFH specifies that the default location be used. If a non- 
default address is specified, the segment base must be 0. The offset must 
place the entire block either between 200H and 3FFH, or between 1000H and 
0FFFFH. 

In the reply message, this field returns the actual address of the NX 200 
movable data area. The reply value is not defined in mode 0. 

3.5.12. Number of Processes Field 

The number of processes field configures the maximum number of processes 
which NX 200 will support. If the EXOS 202 is configured in mode 0, this field 
must be 0FFH. In modes 1 or 2, the value 0FFH specifies that the current value 
be used. The default value, after reset, is 12. Optionally, a value between 1 
and 128 can be specified. In the reply message, this field returns the actual 
number of processes which NX 200 will support. The reply value is not defined 
in mode 0. 

3.5.13. Number of Mailboxes Field 

The number of mailboxes field configures the maximum number of mailboxes 
which NX 200 will support. Note that this number does not include system 
mailboxes. If the EXOS 202 is configured in mode 0, this field must be 0FFH. 
In modes 1 or 2, the value 0FFH specifies that the current value be used. The 
default value, after reset, is 16. Optionally, a value between 1 and 128 can be 
specified. In the reply message, this field returns the actual number of 
mailboxes which NX 200 will support. The reply value is not defined in mode 0. 

3.5.14. Number of Multicast Slots Field 

The number of multicast slots field configures the maximum number of multicast 
address slots which NX 200 will support. Note that this number does not include 
the physical, broadcast, universal, or null slots, which are permanently allocated. 
The value 0FFH specifies that the current value be used. The default value, 
after reset, is 8. Optionally, a value between and 252 can be specified. In the 
reply message, this field returns the actual number of address slots which 
NX 200 will support. 

3.5.15. Number of Hosts Field 

The number of hosts field specifies the number of host CPUs on the VMEbus 
interface. Permissible values depend on the mode of operation. In all modes, 
the value 0FFH will retain the value currently in force. Upon first configuration, 
the default value is 0. In operation modes and 1, only the value 1 may be 
specified. However in mode 2 (network bootstrap), this field can be either or 
1. If 0, then the host message queues are undefined and the configuration 
message fields pertaining to them will not be examined. Its value is preserved 
in the reply message. 
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3.5.16. Host-to-EXOS Message Queue Base Address Field 

The host-to-EXOS message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from the host to the EXOS 202 (refer to Section 3.6.). 
Addresses for all message queue data structures are 16-bit offsets, calculated 
relative to this base. 

This field contains a VMEbus address modifier concatenated with absolute 
memory address stored as a longword. The lower-order 3 bytes contain the 
24-bit physical address; the low-order 6 bits of the most significant byte contain 
the VMEbus address modifier and the remaining 2 bits are reserved and must 
be zero. Furthermore, the lower-order 4 bits of the address must also be 0, so 
that the segment begins on some even 16-byte address boundary. 

This field's value is preserved in the reply message. 

3.5.17. Host-to-EXOS Message Queue Header Address Field 

The host-to-EXOS message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the host-to-EXOS message queue. Its value in the reply message 
is preserved. 

3.5.18. Host-to-EXOS Message Queue Interrupt Type Field 

The host-to-EXOS message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
Host-to-EXOS 202 message queue. Options are: 

No interrupt. The host polls the message queues. 

1 Undefined. 

2 Memory mapped. The EXOS 202 writes a specified value at the 
specified memory address. 

3 Undefined. 

4 Bus-vectored interrupt. 

The value of this field is preserved in the reply message. 

3.5.19. Host-to-EXOS Message Queue Interrupt Value Field 

The host-to-EXOS message queue interrupt value field is defined only for 
memory mapped interrupt type. If interrupt type 2 is selected, then this value 
will be written to the specified memory address when an interrupt is asserted. 
The value of this field is preserved in the reply message. 

3.5.20. Host-to-EXOS Message Queue Interrupt Address Field 

The host-to-EXOS message queue interrupt address field is defined only for 
memory mapped and bus-vectored interrupt type. If interrupt type 2 is selected, 
then it contains a VMEbus memory address, which must follow the host address 
format described in Section 1, Memory Address Format. If interrupt type 4 is 
selected, then the first word contains an interrupt vector; contents of the second 
word are undefined. The value of this field is preserved in the reply message. 
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3.5.21. EXOS-to-Host Message Queue Base Address Field 

The EXOS-tohost message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from NX 200 to the host (refer to Section 3.6). This is 
exactly equivalent to the host-to-EXOS message queue base address field (refer 
to Section 3.5.16). Its value in the reply message is preserved. 

3.5.22. EXOS-to-Hosf Message Queue Header Address Field 

The EXOS-to-host message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the EXOS-to-host message queue. Its value in the reply message 
is preserved. 

3.5.23. EXOS-to-Host Message Queue Interrupt Type Field 

The EXOS-to-host message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
EXOS 202-to-host message queue. Options are: 

No interrupt. The host polls the message queues. 

1 Undefined. 

2 Memory mapped. The EXOS 202 writes a specified value at the 
specified memory address. 

3 Undefined. 

4 t3us-vectored interrupts. 

The value of this field is preserved in the reply message. 

3.5.24. EXOS-to-Host Message Queue Interrupt Value Field 

The EXOS-to-host message queue interrupt value field is defined only for 
memory mapped interrupt type. If interrupt type 2 is selected, then this value 
will be written to the specified memory address when an interrupt is asserted. 
The value of this field is preserved in the reply message. 

3.5.25. EXOS-to-Host Message Queue Interrupt Address Field 

The EXOS-to-host message queue interrupt address field is defined only for 
memory mapped and bus-vectored interrupt types. If interrupt type 2 is 
selected, then it contains a VMEbus memory address, which must follow the 
host address format described in Section 1 . If interrupt type 4 is selected, then 
the first word contains an interrupt vector; contents of the second word are 
undefined. The value of this field is preserved in the reply message. 

3.6. MESSAGE QUEUE FORMAT 

Once the EXOS 202 is configured, message queues in shared memory serve all 
further communications with the host. This includes software download, link 
level controller mode service requests, and communication with downloaded 
protocol code. Two message queues are maintained by the NX 200 firmware, 
one for each direction of transfer. This section describes the format of the data 
structures which compose a message queue. Following sections describe how 
these must be initialized, and then the protocol which ensues after configuration. 
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Each message queue necessarily includes one queue header and a singly- 
linked, circular list of message buffers. The required queue header belongs to 
the EXOS 202; it reads and modifies its value during message exchange. The 
host may read it, but must not modify it. The EXOS 202 queue header and all 
message buffers must lie within a single 64K area of memory, called the queue 
segment. 

Message queue data structures are described here as viewed by NX 200. The 
configuration message provides NX 200 with the queue segment base and the 
offset address of the queue header, for each queue. NX 200 regards the queue 
header value and link field values as 16-bit offsets calculated relative to the 
queue segment base. As long as this view is preserved for NX 200, users are 
perfectly free to augment these data structures in any manner necessary to 
implement the desired mechanisms for the host message handling software. 

Figure 3-5 shows the format of a message buffer, and the following paragraphs 
describe the individual fields in detail. 
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Figure 3-5: Message Buffer Format 



3.6.1. Link Field 

The link field is the address of the next buffer in the circular queue. This 
address must be an offset calculated relative to the queue segment base 
specified in the configuration message. This field is static and should not be 
changed after configuration. 

3.6.2. Reserved Field 

This field is reserved. It must be initialized with the value 0, and set to in 
Host-to-EXOS messages. Its value in reply message is undefined. 
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3.6.3. Status Field 



The status field is used to implement the message protocol, and is defined 
bit by bit: 

Bit 0: Owner bit. If then the buffer is owned by the host; if 1 then 

the buffer is owned by NX 200. The host may alter a 
message buffer only while it has ownership. 

Bit 1 : Done bit. NX 200 sets this to along with the owner bit 

every time it passes a buffer to the host. Host software can 
use the done bit to distinguish between buffers newly 
received from NX 200 and buffers it has already processed. 

Bit 2: Overflow Bit. NX 200 sets this bit to 1 if an EXOS-to-Host 

message had to be truncated because the host buffer's data 
field was shorter than the message sent. 

Bits 3-7: Undefined. These bits are reserved for NX 200, and should 
not be used for any purpose by the host. 



3.6.4. Length Field 



The length field specifies the number of bytes in the data field. The maximum 
length of the data field is a matter of agreement between the host and the user 
software on the EXOS 202. There is no restriction on the size of the data field 
as long as the buffers satisfy the queue segment constraints. Most applications 
will transfer small amounts of control information via messages, and use direct 
memory access to move larger data buffers. 

In Host-to-EXOS messages, set this field's value before passing the message to 
NX 200. In EXOS-to-Host messages, this field tells the host how many valid 
bytes were written into the data field. The host must reset its value to the data 
field's size before returning a buffer to NX 200. 

3.6.5. Data Field 

The data field contains the actual message data passed between the host and 
the EXOS 202. NX 200 does not interpret its contents in any way - it is exactly 
equivalent to the data field in messages as seen by processes on the EXOS 202 
(refer to Section 7). 

3.7. MESSAGE QUEUE INITIALIZATION 

The host must initialize the message queues and the queue headers prior to 
configuring the EXOS 202. Figure 3-6 shows the relation between queue 
headers and message queue buffers at initialization time for a typical 
implementation. In each queue, the host and EXOS 202 queue headers should 
point to the same buffer. 

For each queue, the link fields should be initialized to form a circular, singly- 
linked list. This ring structure should not be modified after configuration. Each 
queue may contain an arbitrary number of buffers, so long as at least one is 
supplied. The reserved field of all message buffers in both queues should be 
set to 0. 
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Figure 3-6: Message Queue Data Structures at Initialization Time 



In the host-to-EXOS queue the status field of all buffers should contain the value 
02H, which indicates that they are owned by the host. The length and data 
fields are not defined at initialization. 

In the EXOS-to-host queue the status field of all buffers should contain the value 
03H, which indicates that they are owned by NX 200. The length field of each 
buffer should not exceed the size of the data buffer. 

Note that the length field must be initialized to accommodate the length of the 
largest message expected from NX 200, or the message will be truncated upon 
reception. The data field is not defined at initialization. 

Figure 3-7 is a snapshot of an example EXOS-to-host message buffer queue at 
the time of initialization. The configuration message describing the queue is also 
shown in part. Data structures are shown as vectors containing hexadecimal 
byte values. The VMEbus physical address of each data structure is shown to 
the left (slightly above the location), and its name to the right. The example 
assumes that the host system's memory is so partitioned that 3DH is the 
VMEbus address modifier which NX 200 should use to address host system 
memory. As a result, all of the 4-byte pointers contain the 3DH address modifier 
concatenated with the 24-bit physical address. According to the configuration 
message in this example, writing the value 40H at memory location 0E2044H 
will interrupt the host. NX 200 will assert this interrupt when the status of the 
EXOS-to-host message queue changes, as described in the following section. 
The circular message queue shown here contains three buffers of equal length, 
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Figure 3-7: Example EXOS-to-Host Message Queue, at Initialization Time 
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each providing a 32-byte data field. The queue header points to one of the 
buffers, arbitrarily chosen, at its link field address. 

3.8. MESSAGE QUEUE PROTOCOL 

This section describes the protocol which NX 200 follows in sending messages 
to, and receiving messages from, the host processor. As it happens, host 
software can follow the same procedure, so that the exchange is symmetrically 
defined. The description below assumes such an implementation, but certainly 
other methods are possible, within the constraints of NX 200's behavior. 

In a typical implementation, the host system and NX 200 each maintain private 
queue headers for both queues (see Figure 3-6). The EXOS 202's host-to- 
EXOS message queue's header points to the message buffer which NX 200 will 
receive next. The EXOS 202's EXOS-to-host message queue's header points 
to the message buffer which NX 200 will send to next. NX 200 maintains these 
queue headers after configuration. Although the EXOS 202 queue headers are 
kept in host memory, after initialization the host should not refer to these. 
Similarly, NX 200 will not refer to the host's own queue headers. Host queue 
headers can be in any format (16-bit offset, 32-bit virtual address, array index, 
etc.) which may be convenient for the host software. 

For the host-to-EXOS queue, the host's queue header should always point to 
the next buffer in which the host will send a message. NX 200's queue header 
will always point to the next buffer in which NX 200 will look for a message. 
Both pointers will always move sequentially through the message queue. Note 
that unless a message arrives on the next buffer, NX 200 will not scan any 
further in the queue. This means that the host should always write the message 
in the next buffer where NX 200 expects it to be rather than in any arbitrary 
position in the queue. During the course of message processing, the host's 
queue header may end up several buffers ahead of NX 200's queue header, but 
should never "lap" it from behind. Any difference between the headers 
represents buffers which NX 200 has not yet consumed. 

For the EXOS-to-host queue, the host's queue header should always point to 
the next buffer in which the host will look for a message. NX 200's queue 
header will always point to the next buffer in which NX 200 will send a message. 
As above, both pointers will always move sequentially through the message 
queue. Note that unless the next buffer is available to the EXOS 202, it will not 
scan any further to find a free buffer to write the message. This means that 
NX 200 will always write the message in the next buffer where the host expects 
it to be rather than in any arbitrary position in the queue. During the course of 
message processing, NX 200's queue header may end up several buffers ahead 
of the host's queue header, but again, should never "lap" it from behind. Any 
difference between the headers represents buffers which the host has not 
yet consumed. 

3.8.1. Host-to-EXOS Message Transfer 

Host software can use the following sequence of steps to transfer messages 
to NX 200: 

1. Test the owner bit of the buffer to which the host queue header 
points. If NX 200 still owns this buffer, then wait until it is returned 
(either poll the owner bit, or wait for the interrupt which 
accompanies each buffer turnover event). 
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2. Advance the host queue header, so that it now points to the next 
buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field appropriately. 

4. Set the current buffer's owner bit, so that the buffer now belongs 
to NX 200. 

5. Interrupt NX 200 by writing to port B, to notify it that a new 
message is available. 

The EXOS 202 can process more than one message from the host upon 
receiving a single interrupt. Therefore it is important that the host change the 
buffer's owner bit only after preparing the other fields. Otherwise, NX 200 if is 
still processing a previous interrupt from the host, it may consume a half-baked 
message. Note that the host may prepare more than one message buffer at a 
time, and send a single interrupt, if sufficient buffers are available. 

When NX 200 receives an interrupt from the host, it will: 

1 . Examine the owner bit of the buffer to which its own queue header 
points. If the buffer belongs to NX 200, then it will process it, as 
described in the following steps. (Otherwise, the interrupt could 
mean that the host is returning an EXOS-to-host message buffer, or 
could be spurious.) 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Extract the message from the current buffer. If there is no 
consumer for this data (no receive request on the NX 200's host 
interface mailbox), then wait. 

4. Reset the current buffer's owner bit, so that the buffer is returned to 
the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a buffer has been returned. The 
type of interrupt is specified by the configuration message. Repeat 
from step 1, until the owner bit shows that no new messages are 
pending. 

Note that the interrupt described in step 5 is the same interrupt which the host 
waits upon when no message buffers are available. 

3.8.2. EXOS-to-Host Message Transfer 

When NX 200 has a message to transfer to the host, NX 200 will: 

1 . Test the owner bit of the buffer to which its queue header points. If 
the buffer belongs to NX 200, then process it, as described in the 
following steps. Otherwise, wait for an interrupt from the host which 
indicates that a buffer has been returned (NX 200 can process 
other jobs in the mean time). 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field to the length actually transferred (will not exceed 
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data field length). If the data field was too short for the message, 
then it sets the overflow bit. 

4. Reset the current buffer's owner bit, so that the buffer now belongs 
to the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a new message is available. The 
type of interrupt is specified by the configuration message. 

When the host receives an interrupt from NX 200, it can: 

1 . Examine the owner bit of the buffer to which the host queue header 

points. If the buffer belongs to the host, then it should process it, 

as described in the following steps. (Otherwise, the interrupt could 

mean that NX 200 is returning a host-to-EXOS message buffer, or 

could be spurious.) 

d 

2. Advance the host's own queue header, so that it now points to the 
next buffer in the queue. 

3. Extract the message from the current buffer. It may check the 
overflow bit to be certain that the entire message was sent. If there 
is no consumer for this data, then wait. 

4. Set the length field to the size of the data field. 

5. Reset the current buffer's owner bit, so that the buffer is returned 
to NX 200. 

6. Interrupt NX 200 by writing to port B, to notify it that a message 
buffer has been returned. Repeat from step 1, until the owner bit 
shows that no new messages are pending. 

While the host is processing an interrupt, NX 200 may in the meantime write 
more messages into the queue. The host may elect to process these messages 
in addition to the message associated with the interrupt being serviced. Note, 
however, that at least one interrupt will remain pending, so that when interrupts 
are re-enabled, the host will be again interrupted by NX 200, although the 
corresponding message would have already been processed. 

Although the above description assumes that the EXOS 202 is programmed to 
interrupt the host to signal message queue events, the host also has the option 
of simply polling the message queue. 

3.9. DOWNLOADING SOFTWARE FROM THE HOST 

Normally, if the EXOS 202 is configured in mode 1, host software would then 
download and run higher level protocol software. Two message formats are 
provided for this purpose, one to copy user code and data to NX 200, and 
another to start code execution. For each message NX 200 sends a 
corresponding reply message which confirms the completion of the request. 

3.9.1. Host Download Request 

The host can copy code to any location in EXOS 202 memory which is normally 
available to the user. The download request copies buffers up to 64K-1 each in 
size, in any order, without modification. NX 200 does not protect the user area 
against un-intentional overlays. Figure 3-8 shows the format of the download 
request/reply message, and the following paragraphs describe the individual 
fields in detail. 
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3.9.1.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 

3.9.1.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

3.9.1.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 0. This value is preserved in the reply message. 



# Length Offset Field Name 



Request Reply 



1) 2 



2) 4 



3) 


1 


6 


4) 


1 


7 


5) 


2 


8 



6) 4 



7) 4 



10 



14 



Reserved for NX Usage 
User Id Code 

Request Code 
Return Code 
Data Length 



Source Address 



Destination Address 



zero 



unde f i ned 



undefined preserved 



00H preserved 

unde f i ned see text 

see text see text 

see text undefi ned 



see text undefined 



I < 1 byte 

Figure 3-8: EXOS 202 Down-Load Request/Reply Message 
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3.9.1.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the download request: 







Successful completion. 



A3H Destination memory block overlaps the memory reserved for 
NX 200, no copy done. 

A1H Invalid request, the EXOS 202 is not in front end mode. 

3.9.1.5. Data Length Field 

The data length field specifies the number of bytes to be copied into EXOS 202 
memory. This may be any value between and 64K-1. In the reply message, 
this field returns the number of bytes actually copied. 

3.9.1.6. Source Address Field 

The source address field specifies the starting address in shared memory from 
which to copy the user code image. This is the absolute address with the 
VMEbus address modifier provided at bit positions 0-5 in the most significant 
byte. Its value in the reply message is undefined. 



# Length Offset Field Name 



Request Reply 



1) 2 



2) 4 



3) 1 6 

4) 1 7 
5)4 8 



Reserved for NX Usage 
User Id Code 

Request Code 
Return Code 
Start i ng Add ress 



zero 



unde f i ned 



undefined preserved 



02H preserved 
unde f i ned see text 
see text p rese r ved 



I < 1 byte > | 

Figure 3-9: EXOS 202 Start-Execution Request/Reply Message 
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3.9.1.7. Destination Address Field 

The destination address field specifies the starting address in EXOS 202 
memory to which the user code image will be copied. This must be a 
segmented address. Its value in the reply message is undefined. 

3.9.2. Start Execution Request 

After downloading protocol software, the host processor starts it executing with 
a single start execution request message. Once this command has been issued 
and the reply received, NX 200 does not itself process any more messages. 
Instead, all messages sent to the EXOS 202 will be queued up for user 
processes running under the NX 200 kernel. 

The start execution request specifies the location at which execution of user 
code begins. User code is entered as a single process with priority 255 and 
infinite time slice. All registers except for the PC and stack pointer are 
undefined. The initial process stack is provided from the NX 200 data area and 
is guaranteed to be at least 100H bytes deep. The process is free to switch to a 
bigger stack if desired. In all other respects, it is a normal process, as defined 
in Section 7.5. 

Figure 3-9 shows the format of the start execution request/reply message, and 
the following paragraphs describe the individual fields in detail. 

3.9.2.1. Reserved Field 

The first field is reserved for use by NX 200, and must be initialized as 0. Its 
value in the reply message is undefined. 

3.9.2.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

3.9.2.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 2. This value is preserved in the reply message. 

3.9.2.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the start execution request. 

Successful completion. 

A2H Invalid starting address, execution not started. 

A1H Invalid request, the EXOS 202 is not in front end mode. 

3.9.2.5. Starting Address Field 

The starting address field specifies the initial value of the initial process's 
program counter. This must be a segmented address. Its value is preserved in 
the reply message. 
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Chapter 4 

INITIALIZATION AND HOST INTERFACE 

FOR Q-BUS SYSTEMS 



4.1. INTRODUCTION 



The EXOS 203 Intelligent Ethernet Controller is specifically designed for use in a 
Q-bus system. This section contains information pertinent to the design of 
host-resident software, such as an I/O driver, which communicates with the 
EXOS 203 intelligent Ethernet controller installed in a Q-bus-based system. 

Note that the EXOS 203 Intelligent Ethernet Controllers are available for use in 
different computer buses, such as, Multibus, Q-bus, UNIBUS, VMEbus, and PC 
bus. While logically the NX 200 operating system functions remain the same, the 
specific procedures for initialization vary for different EXOS board-to-host 
combinations. 

The host interface can be broken down into two aspects, the initialization 
procedure, and the communication method subsequently used. Initialization 
refers to the process which begins upon resetting the EXOS 203, and concludes 
either with entering the Link Level Controller mode, or with the execution of 
downloaded software. During the process of initialization, the host system sets 
up the host message queue data structures. The host message queue protocol, 
defined by NX 200 firmware, uses these queues for all further communications 
between the host processor and NX 200. 

The following paragraphs give an overview of the initialization process: 

1 . The host system resets the EXOS 203, then the NX 200 executes 
self-diagnostics which exercise various board components and 
functions. If the diagnostics fail, then the EXOS 203 displays an 
error code on the NX 200 status LED (see Appendix A, Self- 
Diagnostic and Configuration Errors) until the board is reset again. 
If the diagnostics pass, then NX 200 awaits configuration by 
the host. 

2. The host system passes NX 200 the address of a configuration 
message in host memory. NX 200 examines this message, and 
modifies some fields according to the results of configuration. If 
configuration is unsuccessful, the EXOS 203 displays an error code 
on the NX 200 status LED until reset. If the configuration message 
is valid, then the EXOS 203 enters one of three modes, as 
specified by the operation mode field in the message. 

3. Initialization for each of the three different modes proceeds as 
follows: 

a. In Link Level Controller Mode, the EXOS 203 begins to execute 
firmware which brings NX 200's Ethernet Data Link driver 
interface out to the host system interface. No software is 
downloaded to the EXOS 203; instead the host system passes 
Data Link commands to the board and receives replies through 
the standard host message queue protocol. This mode is 
described fully in Section 6. 
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b. In Front-End Mode 1 , the host system proceeds to download 
software to the EXOS 203, by passing download request 
messages through the standard host message queue protocol. 
After the software has been downloaded, it passes an execute 
request to the board, which then begins to execute the 
downloaded software. Subsequent actions depend entirely on 
the software which has been downloaded, although the host 
message queue protocol remains in place. 

c. In Front-End Mode 2, the EXOS 203 proceeds to bootstrap 
itself from the Ethernet interface, as described in Section 11. 
Depending on how the bootstrap server configures NX 200, it 
may still communicate with the host system through the 
standard host message queue protocol. Network bootstrap is 
quite similar in many ways to initialization by a host processor; 
the configuration message described in this section is identical. 

4.2. HARDWARE COMMUNICATIONS CHANNELS 

Communication between the host processor and the EXOS 203 is conducted via 
a coordinated exchange of interrupts, I/O instructions, and data transfers 
through shared memory on the Q-bus. The following sections define these 
primitive channels of communication. These channels are used during the 
process of initialization and, subsequently, to implement the message queue 
protocol. 

4.2.1. Host Access to the EXOS 203 Q-bus Board 

The host's means of active access to the EXOS 203 are solely through two I/O 
ports, named port A and port B here for the sake of reference. These ports are 
accessed over the Q-bus, and can be both read and written. Their addresses 
are selected by jumpers on the EXOS 203, as described in the EXOS 203 
Intelligent Ethernet Controller Reference Manual. 

The effects of reading and writing ports A and B in Q-bus systems are 
summarized below: 



Read A 
Write A 
Read B 



No Operation. 

Resets the EXOS 203 (refer to Section 4.4). 

Returns the EXOS 203 status byte: 

Bit 0: (Error Bit) when 0, indicates a fatal error in EXOS 203. 

When the EXOS 203 is reset, this bit is 0, but will be 
set to 1 if the self test completes successfully. If this 
bit is not set within 3 seconds, then the EXOS 203 has 
failed the self-diagnostics. 

Bits 1-2: Undefined. 

ESit 3: (Ready Bit) when 0, indicates that NX 200 is ready to 

accept a byte written into port B. When 1 , NX 200 has 
not yet read the byte last written into port B. 

Bits 4-5: Undefined. 
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Bit 6: (Loopback Test Bit) when 0, indicates loopback test 

passed. When 1, indicates loopback test failed, 
possibly due to faulty transceiver or faulty transceiver 
cable. 

Bit 7: Undefined 

Write B: Interrupts the EXOS 203 CPU, and communicates a 1-byte value. 
This is the only way to communicate a value to the EXOS 203 
other than through shared memory. 

4.2.2. EXOS 203 Q-bus Board Access to the Host 

The EXOS 203 functions as a master on a Q-bus system. It can access the full 
4-Mbyte memory address space which includes the 8K I/O address space, and 
interrupt the host processor. User software on the EXOS 203 does not directly 
control these resources. Instead, it calls NX 200's host interface driver, 
described in Section 9. 

In general, data is transferred between the host and the EXOS 203 via shared 
memory, which may be any portion of system memory accessible to both 
processors on the Q-bus. The EXOS 203's CPU performs the transfer by 
dynamically mapping part of its own address space into the Q-bus memory 
address space, and executing a block transfer instruction. Note that the 
EXOS 203's on-board memory cannot be shared; it is not directly accessible by 
the host processor. 

The EXOS 203 can interrupt the host either through I/O addresses, memory 
addresses, or the Q-bus interrupt lines. The type which will be used is selected 
at initialization time. Memory and l/O-mapped interrupt addresses are 
configured by software; the interrupt line is selectable by means of a jumper 
option, described in the EXOS 203 Intelligent Ethernet Controller Reference 
Manual. Unless l/O-mapped interrupts are selected, the NX 200 firmware will 
not normally generate I/O operations on the Q-bus. User software on the 
EXOS 203 can use I/O instructions to control other peripheral cards. 

4.3. HOST DATA ORDER CONVERSION OPTION 

The host data order conversion option determines whether NX 200 will interpret 
data read from host memory according to its own native ordering, or according 
to the host CPU's native ordering. This option is selected by a field in the 
configuration message (refer to Section 4.5.5). If enabled, then the NX 200 
inspects a known data pattern in the configuration message, written in the host 
CPU's native order. It determines what conversions are necessary to make this 
pattern appear in the order it expects, for several different data types: byte 
array, word array, and longword. NX 200 will then apply the appropriate 
conversion to all data objects subsequently read from host memory. 

For the byte array data type, NX 200 knows how to convert data stored 
according to the SUN design's byte addressing idiosyncrasies. This means that 
it will invert the least significant address bit when addressing host system 
memory, to reverse the effects of common 68000 CPU board designs. For the 
word data type, NX 200 can swap bytes if necessary. For the longword data 
type, NX 200 can swap words, swap bytes, or both. Therefore I/O driver 
software for any reasonably normal host CPU can store data objects in its native 
order, and leave conversion up to NX 200. 



4-3 



NX 200: Initialization and Host Interface for Q-bus Systems 

Naturally, NX 200 must know the type of a data object to apply the appropriate 
conversion. All data objects described in this section are known to NX 200, 
except for the actual contents of messages between the host and the 
EXOS 203. NX 200 does apply the byte array conversion (if necessary) to 
message contents, and to all data transferred. How the contents of messages 
should be further interpreted is the function of user-level software running on the 
EXOS 203. For instance, the firmware which drives the Link Level Controller 
Mode (refer to Section 6) runs at user level under NX 200, and converts word 
and longword data objects which are known to itself, but not to NX 200. NX 200 
assists this process by providing kernel calls (refer to Section 9.5) which convert 
word and longword data types as required by the host data order conversion 
option. 

Whether or not the host data order conversion option is enabled, the host 
system must still write the required data pattern in the configuration message. 
This pattern occupies 12 bytes of the 32-byte test pattern/memory map field 
(refer to Section 4.5.10). It should be initialized as shown in Figure 4-1. Note 
that while the relative position of subfields in the test pattern is specified, the 
order of bytes within those subfields is dependent on the host CPU architecture. 
Figure 4-2 shows how this pattern might be initialized in the C language, both 
statically and dynamically. 



Length Offset Sub-Field Name 
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1 





2) 
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3) 
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5) 
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Byte 
Byte 1 



Byte 2 
Byte 3 
Word 



Word 1 



Longwo r d 



01H 
03H 
07H 
0FH 
0103H 

070FH 

0103070FH 



8) 20 



12 



Re s e r v e d 



I - 1 b y t e 

Figure 4-1 : Host Data Order Conversion Option Test Pattern 
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Note that memory addresses, regardless of the host address mode, are stored 
and interpreted as the longword data type. For instance, the longword test 
pattern can also be regarded as a memory address in the host's native format 
for the absolute address 0103070FH (if absolute address mode is selected) or 
for segment 070FH, offset 0103H (if segmented mode is selected). 



/* constants for test pattern */ 
#defineBYTE0 0x01 
#define BYTE1 0x03 
#define BYTE2 0x07 
#define BYTE3 OxOF 
#define WORD0 0x0103 
#define WORD1 0x070F 
#define DWORD 0x01 03070 F 

/* static initialization of test pattern 7 
struct tstptrn { 

char byteptm[4j; 

short wordptm[2]; 

long Iwordptrn; 

char rsrvd[20); 



struct tstptrn tp = { 

BYTEO, BYTE1, BYTE2, BYTE3, 
WORDO, WORD1 , 
DWORD, 
0,0,0,0,0,0.0,0,0,0,0,0,0,0,0,0,0,0,0,0 

}; 

/* dynamic initialization of test pattern */ 
initptm () 

I 

register int i; 

tp.byteptm[0] = BYTEO; 

tp.byteptrn[1] = BYTE1 ; 

tp.byteptrn[2] = BYTE2; 

tp.byteptrn[3] = BYTE3; 

tp.wordptm[0] = WORDO; 

tp.wordptrn[1] = WORD1 ; 

tp.lwordptrn = DWORD; 

for (i = 0; i<20; i+ + ) tp.rsrvd[i] = 0; 
} 
Figure 4-2: Host Data Format Test Pattern Initialization 



If NX 200 cannot make any sense of the test pattern presented by the host, 
then initialization is aborted, and the appropriate error code displayed on the 
status LED. For error code value assignments, see Appendix A; Self- Diagnostic 
and Configuration Errors. 
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4.4. RESET AND CONFIGURATION PROCEDURE 

This section describes initialization by a host system up to the completion of 
configuration. Figure 4-3 shows a typical procedure which implements as much. 

The EXOS 203 is reset by the Q-bus BINIT signal, or whenever port A is written 
from the Q-bus. Host software should use the latter method to be sure. On 
reset of the EXOS 203, NX 200 performs a Series of self tests to confirm 
hardware integrity. While these tests run, the NX 200 status LED (see Appendix 
A; Self-Diagnostics and Configuration) will remain lit constantly. 
When self-diagnostics complete successfully, NX 200 sets the error bit in I/O 
port B and flashes the status LED at regular intervals. 

If the error bit is not set within 3 seconds of reset, the host may assume that 
self-diagnostics turned up a problem. In this case, the EXOS 203 repeatedly 
reports an error code through the NX 200 status LED (for error code values, see 
Appendix A; Self-Diagnostic and Configuration Errors). The EXOS 203 will 
remain in this state until reset again. 

A jumper option, described in the EXOS 203 Intelligent Ethernet Controller 
Reference Manual, determines how initialization will proceed after reset and 
self-diagnostics. If the jumper selects network bootstrap, then the EXOS 203 
will attempt to download software over the Ethernet (refer to Section 11). 
Otherwise the EXOS 203 awaits configuration by the host processor. 

The host configures the EXOS 203 by passing it the address of a configuration 
message, located in shared memory. This message establishes various NX 200 
parameters and selects among several modes of operation. Parameters include 
memory allocation for NX 200 objects, the address of NX 200s movable data 
area in EXOS 203 memory, and the location of message queues in shared 
memory. 

Among the optional operation modes, the host can select network bootstrap. 
This will proceed as though the net boot jumper option had been installed, 
except that NX 200 will first note the contents of the host configuration 
message. Other configuration options include host data order conversion and 
the host address mode. 

The host processor communicates the address of the configuration message to 
NX 200 by writing a sequence of 8 bytes into port B. Each byte should be 
written after checking that the ready bit of the EXOS 203's port B is clear. This 
ensures that the EXOS Q-bus board is ready to accept the next address byte. 
The first four bytes of the sequence must be FF-FF-00-00 (sent from left to 
right). The next four bytes are the configuration message's absolute Q-bus 
memory address (least significant byte first). The configuration message must 
be aligned on a even address boundary. When the last byte is written, NX 200 
reads and interprets the configuration message. If the address for the 
initialization message is not valid, then NX 200 will display an error code on the 
status LED (see Appendix A; Self-Diagnostic and Configuration Errors). 

When NX 200 has finished processing the configuration message, it writes a 
completion code into the appropriate field of the message. Any value other than 
0FFH indicates completion; the value indicates successful configuration. 
Other values denote specific errors in configuration (refer to Section 4.5.3). 
Normally, configuration should complete within 3 seconds, but network bootstrap 
might take longer, depending on circumstance. NX 200 also returns a few 
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extern read_port(Port_Num) /* returns value read from port Port_Num 7 
extern write_port(Port_Num, Val) /* writes Val to port PorLNum 7 
extern start_clock() /* starts an interval timer 7 
extern clock() /* returns the current value of the interval timer 7 

/* bit value definitions for status byte read from port B 7 
#define ERROFLBIT 1 
#define READY.BIT 8 
#define ERRNON 

struct { /" configuration message 7 

short reserved; 

char version[4); 

char comp_code; 
<etc. .> 
| init_msg; 

char init_addrs[8] = {OxFF, OxFF, 0. 0. <absolute address of init msg> ); 
/' refer to Section 1 for absolute address format 7 

initialize () { 

< set up init_msg and the message queues (refer to Section 4.6) >; 

write-port(A); /* reset the EXOS 203 7 

start_clock(); /* start timer, clock counts real time 7 

/* wait until self test completes 7 
while ((read_port(B) & ERROR_BI1") = = ) { 
if (clock() > 2_SECONDS) { 
return (malfunctioning_board); 

} 
I 

/* write the configuration message address 7 
for (i=0; i<8; i++) { 

while (read_port(B) & READY_BIT); 

write_port(B,init_addrs[i]); 

> 

/" wait for the reply message 7 

while (init_msg.comp_code == OxFF); 

/" ensure no errors 7 

if (initjTisg.comp_code != ERRNON) 

return (error); 
else 

return (success); 
I 
Figure 4-3: Typical Reset and Configuration Procedure 



parameters to the host in the configuration message, notably its version number 
and a map of available memory. 

Once configuration is complete, the memory space occupied by the 
configuration message can be used for any other purpose. After configuration, 
communication between the host and NX 200 is carried out solely by means of 
message queues, described in Section 4.5. 
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4.5, CONFIGURATION MESSAGE FORMAT 

Figure 4-4 shows the format of the configuration request/reply message. This is 
used identically by either a host system or a network bootstrap server. The 
following paragraphs explain the individual fields in detail. Note that reply values 
other than the completion code field itself are defined only if configuration is 
successful. 

4.5.1. Reserved Field 

The first field is reserved for use by NX 200. Its value in the request message 
must be 1, and its return value is undefined. 

4.5.2. EXOS Version Code Field 

The EXOS version code field is undefined in the request message. In the reply 
message, it returns version codes for NX 200 and the EXOS 203 in the form 
X.Y and A.B, respectively. These are expressed as ASCII digits, one per byte 
in the order X-Y- A-B, starting from the lower address. 



4.5.3. Configuration Completion Code Field 

The completion code field must be 0FFH in the request message. The 
EXOS 203 signals that configuration is complete, and returns the completion 
code, by writing one of the following codes into this field: 

00H Successful completion. 

A4H Invalid operation mode. 

A5H Invalid host data format test pattern. This occurs when NX 200 
cannot find any reasonable conversion to derive the expected 
data pattern from that supplied in the test pattern. In practice, 
this might imply that the host has given NX 200 the wrong 
address for the configuration message. 

A7H Invalid configuration message format. This may occur if 
reserved fields contain an improper value. In practice, this error 
message may indicate that the host has given NX 200 the 
wrong address for the configuration message. 

A8H Invalid movable block address. 

A9H Invalid number of processes. 

AAH Invalid number of mailboxes. 

ABH Invalid number of address slots. 

ACH Invalid number of hosts. 

ADH Invalid host message queue parameter. NX 200 returns this 
error if it detects any inconsistency in the message queue 
specifications. This might include a bad interrupt type, invalid 
segment address, bad linking of the message queue 
buffers, etc. 
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# Length Offset Field Name 



D 2 



2) 4 



3) 


1 


6 


4) 


1 


7 


5) 


2 


8 



6) 3 

7) 1 

8) 1 

9) 1 
10) 32 



10 

13 
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16 



Rese r ved 



EXOS Version Code 



Configuration Completion Code 
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Host Data Format Option 
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Host Address Mode 

Rese r ved 

Memory Map Size 

Test Pa t t e r n /Memo ry Map 



Request Reply 



unde f i ned 



unde fined see t ex t 



OFFH 



ze r o 
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4.5.4. NX 200 Operation Mode Field 

The NX 200 operation mode field determines the mode in which the EXOS 203 
is to be used. Three different modes are supported: 

Link Level Controller Mode. This mode brings the Ethernet Data 
Link interface out to the host interface. No software is 
downloaded. It would typically be used when the EXOS 203 is 
substituted for the traditional non-programmable Ethernet 
controller board. For details, refer to Section 6. 

1 Front-End Mode, download from the host. In this mode NX 200 
is used as a front-end processor. Higher level software is 
downloaded by the host. 

2 Front-End Mode, download from the net. In this mode NX 200 
is used as a front-end processor and higher level software is 
downloaded from the network. For details, refer to Section 1 1 . 

All other values for the mode are reserved and their effects are not defined. If 
NX 200 is already in the process of network bootstrap (meaning that the 
configuration message has been received from a bootstrap server) then only 
mode 2 is permitted. 

4.5.5. Host Data Order Option Field 

The host data order option field enables the host data order conversion option 
(refer to Section 4.3). Because the byte order of the host CPU will not be 
known before initialization, this field is actually treated as two one-byte fields. 
The host should load the same value into each sub-field in the request 
message. This value is defined bitwise: 

Bit 0: Deduce Format Bit. If 0, NX 200 will apply the conversions 

currently in force. If the board has not been previously 
configured, then the default conversion will be in force, 
meaning that no format conversions are applied to data read 
from the host. If this bit is 1 , then NX 200 examines a 
constant data pattern written by the host in the configuration 
message's test pattern/memory map field, and deduces what 
format conversion are necessary to interpret various data 
types stored in the host CPU's native format. 

Bits 1 -7: Reserved. These bits must be in the request message. 

When initialized, NX 200 examines this field first, and interprets all other fields in 
the configuration message accordingly. This field is undefined in the reply 
message. 

4.5.6. EXOS Context 

This 3-byte field returns the EXOS context information. In the request message 
the value of this field must be zero. In the reply message, the middle byte 
(offset 11) returns the context value; the other two bytes are undefined. For the 
EXOS 203 the context value must be 03. 
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4.5.7. Host Address Mode Field 

The host address mode field determines how NX 200 will interpret addresses 
which refer to objects in host memory. It is defined bitwise: 

Bit 0: Set Mode Bit. If 0, NX 200 will use the address mode 

currently in force. If the board has not been previously 
configured, then the default mode will be in force, meaning 
that NX 200 will interpret all addresses as -style segmented 
addresses. If this bit is 1 , then the next bit determines the 
new address mode. 

Bit 1 : Address Mode Bit. The value selects segmented address 

mode. The value 1 selects absolute address mode. 

Bits 2-7: Reserved. These bits must be zero in the request message. 

This field is undefined in the reply message. 

4.5.8. Reserved Field 

This field is reserved for future use. Its value in the request message must be 
0. Its value in the reply message is undefined. 

4.5.9. Memory Map Size Field 

The memory map size field must be in the request message. In the reply 
message, it returns the number of segments available in EXOS 203 memory for 
user software. This field contains a valid value only if the EXOS 203 is 
configured in mode 1 or mode 2. 

4.5.10. Test Pattern/Memory Map Field and Maximum Packet Size 

The test pattern/memory map field serves different purposes in the request and 
reply messages. In the request message, it must contain the test pattern 
described in Section 4.3, stored in the host CPU's native format. 

In the reply message, the test pattern/memory map field contains a map of 
memory available for user software on NX 200. This map consists of up to 4 
segment descriptors, where the actual number is indicated by the last field. 
Each segment descriptor specifies a memory segment in terms of the lowest 
address and the highest address included within the segment. Each address is 
four bytes long, in the segmented format. The lower bound is given first, then 
the upper bound. 

This field contains a valid value only if the EXOS 203 is configured in mode 1 or 
mode 2. If the optional 128K of RAM between 20000H and 3FFFFH is either 
absent or is malfunctioning, then the map will not contain this segment. 

The above feature is also available to customers using the NX 200, Versions 5.3 
or later, in link-level controller and download modes. The host software may load 
the word at offset 34 from the beginning of the configuration message with a 
maximum packet size, excluding the CRC field. If the specified size is greater 
than 1514 bytes, NX 200 allows larger packets to be transmitted and received 
over Ethernet. The maximum packet size for non-buffer-chaining is 3FFFH. This 
mode, however, should be used with caution, since it allows for violating 
Ethernet specifications. 
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4.5.11. NX 200 Movable Block Address Field 

The NX 200 movable block address field can be used to redefine the location of 
NX 200's movable data area, described in Section 7.3. If the EXOS 203 is 
configured in mode 0, this field must be 0FFFFH, OFFFFH. In modes 1 or 2, the 
value OFFFFH, OFFFFH specifies that the default location be used. If a non- 
default address is specified, the segment base must be 0. The offset must 
place the entire block either between 200H and 3FFH, or between 1000H and 
OFFFFH. 

In the reply message, this field returns the actual address of the NX 200 
movable data area. The reply value is not defined in mode 0. 

4.5.12. Number of Processes Field 

The number of processes field configures the maximum number of processes 
which NX 200 will support. If the EXOS 203 is configured in mode 0, this field 
must be 0FFH. In modes 1 or 2, the value 0FFH specifies that the current value 
be used. The default value, after reset, is 12. Optionally, a value between 1 
and 128 can be specified. In the reply message, this field returns the actual 
number of processes which NX 200 will support. The reply value is not defined 
in mode 0. 

4.5.13. Number of Mailboxes Field 

The number of mailboxes field configures the maximum number of mailboxes 
which NX 200 will support. Note that this number does not include system 
mailboxes. If the EXOS 203 is configured in mode 0, this field must be 0FFH. 
In modes 1 or 2, the value 0FFH specifies that the current value be used. The 
default value, after reset, is 16. Optionally, a value between 1 and 128 can be 
specified. In the reply message, this field returns the actual number of 
mailboxes which NX 200 will support. The reply value is not defined in mode 0. 

4.5.14. Number of Multicast Slots Field 

The number of multicast slots field configures the maximum number of multicast 
address slots which NX 200 will support. Note that this number does not include 
the physical, broadcast, universal, or null slots, which are permanently allocated. 
The value 0FFH specifies that the current value be used. The default value, 
after reset, is 8. Optionally, a value between and 252 can be specified. In the 
reply message, this field returns the actual number of address slots which 
NX 200 will support. 

4.5.15. Number of Hosts Field 

The number of hosts field specifies the number of host CPUs on the Q-bus 
interface. Permissible values depend on the mode of operation. In all modes, 
the value 0FFH will retain the value currently in force. Upon first configuration, 
the default value is 0. In operation modes and 1, only the value 1 may be 
specified. However in mode 2 (network bootstrap), this field can be either or 
1. If 0, then the host message queues are undefined and the configuration 
message fields pertaining to them will not be examined. Its value is preserved 
in the reply message. 
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4.5.16. Host-to-EXOS Message Queue Base Address Field 

The hosMo-EXOS message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from the host to the EXOS 203 (refer to Section 4.6). 
Addresses for all message queue data structures are 16-bit offsets, calculated 
relative to this base. NX 200's interpretation of this base address depends on 
the host address mode selected (see the EXOS 203 Intelligent Ethernet 
Controller Reference Manual). 

In segmented mode, this field must contain an -style segmented address, stored 
according to the convention described for the longword data type (lower-order 
16 bits contain the offset, higher-order 16 bits contain the segment). The offset 
value of this address must be 0; therefore the segment begins on some even 
16-byte address boundary. Note that this format is sufficient only to describe a 
20-bit address, or 1 Mbyte of host memory. 

In absolute mode this field contains a 22-bit absolute memory address, also 
stored as a longword. The lower-order 22 bits contain the address; the 
remaining high-order 10 bits are reserved and must be 0. Furthermore, the 
lower-order 4 bits of the address must also be 0, so that the segment begins on 
some even 16-byte address boundary. This format can describe 4 Mbytes of 
host memory. 

This field's value is preserved in the reply message. 

4.5.17. Host-to-EXOS Message Queue Header Address Field 

The host-to-EXOS message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the host-to-EXOS message queue. Its value in the reply message 
is preserved. 

4.5.18. Host-to-EXOS Message Queue Interrupt Type Field 

The host-to-EXOS message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
Host-to-EXOS 203 message queue. Options are: 

No interrupt. The host polls the message queues. 

1 I/O mapped. NX 200 writes a specified value at the specified 
I/O port address. 

2 Memory mapped. NX 200 writes a specified value at the 
specified memory address. 

3 Undefined. 

4 Bus-vectored interrupt. 

The value of this field is preserved in the reply message. 
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4.5.19. Host-to-EXOS Message Queue Interrupt Value Field 

The host-to-EXOS message queue interrupt value field is defined only for I/O 
mapped or memory mapped interrupt types. If these interrupt types are 
selected, then this value will be written to the specified I/O port or memory 
address when an interrupt is asserted. The value of this field is preserved in the 
reply message. 

4.5.20. Host-to-EXOS Message Queue Interrupt Address Field 

The host-to-EXOS message queue interrupt address field is defined only for I/O 
mapped, memory mapped, and bus-vectored interrupt types. If interrupt type 1 
is selected, then it contains an 8-bit or 16-bit Q-bus I/O port address in the first 
word, and the remaining word is undefined. If interrupt type 2 is selected, then it 
contains a Q-bus memory address, which NX 200 will interpret according to the 
host address mode. If interrupt type 4 is selected, then the first word contains an 
interrupt vector; contents of the second word are undefined. The value of this 
field is preserved in the reply message. 

4.5.21. EXOS-to-Host Message Queue Base Address Field 

The EXOS-to-host message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from NX 200 to the host (refer to Section 4.6). This is 
exactly equivalent to the host-to-EXOS message queue base address field (refer 
to Section 4.5.16). Its value in the reply message is preserved. 

4.5.22. EXOS-to-Host Message Queue Header Address Field 

The EXOS-to-host message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the EXOS-to-host message queue. Its value in the reply message 
is preserved. 

4.5.23. EXOS-to-Host Message Queue Interrupt Type Field 

The EXOS-to-host message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
EXOS 203-to-host message queue. Options are: 

No interrupt. The host polls the message queues. 

1 I/O mapped. NX 200 writes a specified value at the specified 
I/O port address. 

2 Memory mapped. NX 200 writes a specified value at the 
specified memory address. 

3 Undefined. 

4 Bus-vectored interrupts. 

The value of this field is preserved in the reply message. 

4.5.24. EXOS-to-Host Message Queue Interrupt Value Field 

The EXOS-to-host message queue interrupt value field is defined only for I/O 
mapped or memory mapped interrupt types. If these interrupt types are 
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selected, then this value will be written to the specified I/O port or memory 
address when an interrupt is asserted. The value of this field is preserved in the 
reply message. 

4.5.25. EXOS-to-Host Message Queue Interrupt Address Field 

The EXOS-to-host message queue interrupt address field is defined only for I/O 
mapped, memory mapped, and bus-vectored interrupt types. If interrupt type 1 
is selected, then it contains an 8-bit or 16-bit Q-bus I/O port address in the first 
word, and the remaining word is undefined. If interrupt type 2 is selected, then it 
contains a Q-bus memory address, which NX 200 will interpret according to the 
host address mode. If interrupt type 4 is selected, then the first word contains 
an interrupt vector; contents of the second word are undefined. The value of 
this field is preserved in the reply message. 

4.6. MESSAGE QUEUE FORMAT 

Once the EXOS 203 is configured, message queues in shared memory serve all 
further communications with the host. This includes software download, link 
level controller mode service requests, and communication with downloaded 
protocol code. Two message queues are maintained by the NX 200 firmware, 
one for each direction of transfer. This section describes the format of the data 
structures which compose a message queue. Following sections describe how 
these must be initialized, and then the protocol which ensues after configuration. 

Each message queue necessarily includes one queue header and a singly- 
linked, circular list of message buffers. The required queue header belongs to 
the EXOS 203; it reads and modifies its value during message exchange. The 
host may read it, but must not modify it. The EXOS 203 queue header and all 
message buffers must lie within a single 64K area of memory, called the queue 
segment. 

Message queue data structures are described here as viewed by NX 200. The 
configuration message provides NX 200 with the queue segment base and the 
offset address of the queue header, for each queue. NX 200 regards the queue 
header value and link field values as 16-bit offsets calculated relative to the 
queue segment base. As long as this view is preserved for NX 200, users are 
perfectly free to augment these data structures in any manner necessary to 
implement the desired mechanisms for the host message handling software. 

Figure 4-5 shows the format of a message buffer, and the following paragraphs 
describe the individual fields in detail. 

4.6.1. Link Field 

The link field is the address of the next buffer in the circular queue. This 
address must be an offset calculated relative to the queue segment base 
specified in the configuration message. This field is static and should not be 
changed after configuration. 

4.6.2. Reserved Field 

This field is reserved. It must be initialized with the value 0, and set to in 
Host-to-EXOS messages. Its value in reply message is undefined. 



4-16 



NX 200: Initialization and Host Interface for Q-bus Systems 



# Length Offset Field Name 



1) 2 

2) 1 

3) 1 

4) 2 

5) n 



Link 



I Reserved 

Status 

Leng t h 

Data 



1 byte- 



Figure 4-5: Message Buffer Format 



4.6.3. Status Field 



The status field is used to implement the message protocol, and is defined bit by 
bit: 



BitO: 



Bit 1: 



Bit 2: 



Bits 3-7: 



Owner bit. If then the buffer is owned by the host; if 1 then 
the buffer is owned by NX 200. The host may alter a 
message buffer only while it has ownership. 

Done bit. NX 200 sets this to along with the owner bit 
every time it passes a buffer to the host. Host software can 
use the done bit to distinguish between buffers newly 
received from and buffers it has already processed. 

Overflow Bit. NX 200 sets this bit to 1 if an EXOS-to-Host 
message had to be truncated because the host buffer's Data 
Field was shorter than the message sent. 

undefined. These bits are reserved for NX 200, and should 
not be used for any purpose by the host. 



4.6.4. Length Field 



The length field specifies the number of bytes in the data field. The maximum 
length of the data field is a matter of agreement between the host and the user 
software on the EXOS 203. There is no restriction on the size of the data field 
as long as the buffers satisfy the queue segment constraints. Most applications 
will transfer small amounts of control information via messages, and use direct 
memory access to move larger data buffers. 
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In Host-to-EXOS messages, set this field's value before passing the message to 
NX 200. In EXOS-to-Host messages, this field tells the host how many bytes 
were written after a message is transferred. The host must reset its value to the 
data field's size before returning a buffer to NX 200. 

4.6.5. Data Field 

The data field contains the actual message data passed between the host and 
NX 200. NX 200 does not interpret its contents in any way - it is exactly 
equivalent to the data field in messages as seen by processes on the EXOS 203 
(refer to Section 7). However, if the host data order conversion option is 
enabled, and SUN-style address bit inversion is required, this conversion will be 
applied to the contents of the data field. 

4.7. MESSAGE QUEUE INITIALIZATION 

The host must initialize the message queues and the queue headers prior to 
configuring the EXOS 203. Figure 4-6 shows the relation between queue 
headers and message queue buffers at initialization time for a typical 
implementation. In each queue, the host and EXOS 203 queue headers should 
point to the same buffer. 
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Figure 4-6: Message Queue Data Structures at Initialization Time 
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For each queue, the link fields should be initialized to form a circular, singly- 
linked list. This ring structure should not be modified after configuration. Each 
queue may contain an arbitrary number of buffers, so long as at least one is 
supplied. The reserved field of all message buffers in both queues should be 
set to 0. 

In the host-to-EXOS queue the status field of all buffers should contain the value 
02H, which indicates that they are owned by the host. The length and data 
fields are not defined at initialization. 

In the EXOS-to-host queue the status field of all buffers should contain the value 
03H, which indicates that they are owned by NX 200. The length field of each 
buffer should not exceed the size of the data buffer. Note that the length field 
must be initialized to accommodate the length of the largest message expected 
from NX 200, or the message will be truncated upon reception. The data field is 
not defined at initialization. 

Figure 4-7 is a snapshot of an example EXOS-to-host message buffer queue at 
the time of initialization. This example assumes a PDP-11 host system, where 
the EXOS 203 is configured in the segmented host address mode. The 
configuration message describing the queue is also shown in part. Data 
structures are shown as vectors containing hexadecimal byte values. The Q- 
bus physical address of each data structure is shown to the left (slightly above 
the location), and its name to the right. According to the configuration message 
in this example, writing the value 40H at memory location 0E2044H will interrupt 
the host. NX 200 will assert this interrupt when the status of the EXOS-to-host 
message queue changes, as described in the following section. The circular 
message queue shown here contains three buffers of equal length, each 
providing a 32-byte data field. The queue header points to one of the buffers, 
arbitrarily chosen, at its link field address. 

4.8. MESSAGE QUEUE PROTOCOL 

This section describes the protocol which NX 200 follows in sending messages 
to, and receiving messages from, the host processor. As it happens, host 
software can follow the same procedure, so that the exchange is symmetrically 
defined. The description below assumes such an implementation, but certainly 
other methods are possible, within the constraints of NX 200's behavior. 

In a typical implementation, the host system and NX 200 each maintain private 
queue headers for both queues (see Figure 4-6). NX 200's host-to-EXOS 
message queue's header points to the message buffer which NX 200 will 
receive next. NX 200's EXOS-to-host message queue's header points to the 
message buffer which NX 200 will send to next. NX 200 maintains these queue 
headers after configuration. Although NX 200 queue headers are kept in host 
memory, after initialization the host should not refer to these. Similarly, NX 200 
will not refer to the host's own queue headers. Host queue headers may be of 
any format (16-bit offset, 32-bit virtual address, array index, etc.) which is most 
convenient to the host software. 

NX 200 queue, the host's queue header should always point to the next buffer in 
which the host will send a message. NX 200's queue header will always point to 
the next buffer in which NX 200 will look for a message. Both pointers will 
always move sequentially through the message queue. Note that unless a 
message arrives on the next buffer, NX 200 will not scan any further in the 
queue. This means that the host should always write the message in the next 
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Figure 4-7: Example EXOS-toHosI Message Queue, at Initialization 
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buffer where NX 200 expects it to be rather than in any arbitrary position in the 
queue. During the course of message processing, the host's queue header may 
end up several buffers ahead of NX 200's queue header, but should never "lap" 
it from behind. Any difference between the headers represents buffers which 
NX 200 has not yet consumed. 

For the EXOS-to-host queue, the host's queue header should always point to 
the next buffer in which the host will look for a message. The EXOS 203's 
queue header will always point to the next buffer in which NX 200 will send a 
message. As above, both pointers will always move sequentially through the 
message queue. Note that unless the next buffer is available to NX 200 , it will 
not scan any further to find a free buffer to write the message. This means that 
NX 200 will always write the message in the next buffer where the host expects 
it to be rather than in any arbitrary position in the queue. During the course of 
message processing, NX 200's queue header may end up several buffers ahead 
of the host's queue header, but again, should never "lap" it from behind. Any 
difference between the headers represents buffers which the host has not yet 
consumed. 

4.8.1. Host-to-EXOS Message Transfer 

Host software can use the following sequence of steps to transfer messages to 
NX 200: 

1. Test the owner bit of the buffer to which the host queue header 
points. If NX 200 still owns this buffer, then wait until it is returned 
(either poll the owner bit, or wait for the interrupt which 
accompanies each buffer turnover event). 

2. Advance the host queue header, so that it now points to the next 
buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field appropriately. 

4. Set the current buffer's owner bit, so that the buffer now belongs to 
NX 200. 

5. Interrupt NX 200 by writing to port B, to notify it that a new 
message is available. 

NX 200 can process more than one message from the host upon receiving a 
single interrupt. Therefore it is important that the host change the buffer's owner 
bit only after preparing the other fields. Otherwise, if NX 200 is still processing a 
previous interrupt from the host, it may consume a half-baked message. Note 
that the host may prepare more than one message buffer at a time, and send a 
single interrupt, if sufficient buffers are available. 

When NX 200 receives an interrupt from the host, it will: 

1 . Examine the owner bit of the buffer to which its own queue header 
points. If the buffer belongs to NX 200, then it will process it, as 
described in the following steps. (Otherwise, the interrupt could 
mean that the host is returning an EXOS-to-host message buffer, or 
could be spurious.) 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 
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3. Extract the message from the current buffer. If there is no 
consumer for this data (no receive request on the NX 200's host 
interface mailbox), then wait. 

4. Reset the current buffer's owner bit, so that the buffer is returned to 
the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a buffer has been returned. The 
type of interrupt is specified by the configuration message. Repeat 
from step 1, until the owner bit shows that no new messages are 
pending. 

Note that the interrupt described in step 5 is the same interrupt which the host 
waits upon when no message buffers are available. 

4.8.2. EXOS-to-Host Message Transfer 

When the EXOS 203 has a message to transfer to the host, NX 200 will: 

1 . Test the owner bit of the buffer to which its queue header points. If 
the buffer belongs to NX 200, then process- it, as described in the 
following steps. Otherwise, wait for an interrupt from the host which 
indicates that a buffer has been returned (NX 200 can process 
other jobs in the mean time). 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field to the length actually transferred (it will not exceed 
data field length). If the data field was too short for the message, 
then it sets the overflow bit. 

4. Change the current buffer's owner bit, so that the buffer now 
belongs to the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a new message is available. The 
type of interrupt is specified by the configuration message. 

When the host receives an interrupt from NX 200, it can: 

1 . Examine the owner bit of the buffer to which the host queue header 
points. If the buffer belongs to the host, then it should process it, 
as described in the following steps. (Otherwise, the interrupt could 
mean that NX 200 is returning a host-to-EXOS message buffer, or 
could be spurious.) 

2. Advance the host's own queue header, so that it now points to the 
next buffer in the queue. 

3. Extract the message from the current buffer. It may check the 
overflow bit to be certain that the entire message was sent. If there 
is no consumer for this data, then wait. 

4. Set the length field to the size of the data field. 

5. Set the current buffer's owner bit, so that the buffer is returned to 
NX 200. 
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6. Interrupt NX 200 by writing to port B, to notify it that a message 
buffer has been returned. Repeat from step 1, until the owner bit 
shows that no new messages are pending. 

While the host is processing an interrupt, NX 200 may in the meantime write 
more messages into the queue. The host may elect to process these messages 
in addition to the message associated with the interrupt being serviced. Note, 
however, that at least one interrupt will remain pending, so that when interrupts 
are re-enabled, the host will be again interrupted by NX 200, although the 
corresponding message would have already been processed. 

Although the above description assumes that the EXOS 203 is programmed to 
interrupt the host to signal message queue events, the host also has the option 
of simply polling the message queue. 

4.9. DOWNLOADING SOFTWARE FROM THE HOST 

Normally, if the EXOS 203 is configured in mode 1 , host software would then 
download and run higher level protocol software. Two message formats are 
provided for this purpose, one to copy user code and data to the EXOS 203, 
and another to start code execution. For each message NX 200 sends a 
corresponding reply message which confirms the completion of the request. 

4.9.1. Host Download Request 

The host can copy code to any location in EXOS 203 memory which is normally 
available to the user. The download request copies buffers up to 64K-1 each in 
size, in any order, without modification. NX 200 does not protect the user area 
against un-intentional overlays. 

Figure 4-8 shows the format of the download request/reply message, and the 
following paragraphs describe the individual fields in detail. 

4.9.1.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 

4.9.1.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

4.9.1.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 0. This value is preserved in the reply message. 
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# Length Offset Field Name 



1) 2 



2) 4 



3) 


1 


6 


4) 


1 


7 


5) 


2 


8 



6) 4 



10 



7) 4 



1 4 



Reserved for NX Usage 



User Id Code 



Request Code 
Return Code 



Data Length 



Source Address 



Destination Ad dress 



\< 1 byte- 
Figure 4-8: EXOS 203 Down-Load Request/Reply Message 



Request Reply 



zero 



unde f i ned 



undefined preserved 



00H preserved 

undefined see text 

see text see text 

see text unde f i ned 



see text undefined 



4.9.1.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the download request: 

successful completion. 

A3H destination memory block overlaps the memory reserved for 
NX 200, no copy done. 

A1 H invalid request, the EXOS 203 is not in front end mode. 

4.9.1.5. Data Length Field 

The data length field specifies the number of bytes to be copied into EXOS 203 
memory. This may be any value between and 64K-1. In the reply message, 
this field returns the number of bytes actually copied. 
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4.9.1.6. Source Address Field 

The source address field specifies the starting address in shared memory from 
which to copy the user code image. This may be either a segmented or an 
absolute address, depending on the host address mode option. Its value in the 
reply message is undefined. 

4.9.1.7. Destination Address Field 

The destination address field specifies the starting address in EXOS 203 
memory to which the user code image will be copied. This must be a 
segmented address. Its value in the reply message is undefined. 

4.9.2. Start Execution Request 

After downloading protocol software, the host processor starts it executing with 
a single start execution request message. Once this command has been issued 
and the reply received, NX 200 does not itself process any more messages. 
Instead, all messages sent to the EXOS 203 will be queued up for user 
processes running under the NX 200 kernel. 

The start execution request specifies the location at which execution of user 

code begins. User code is entered as a single process with priority 255 and 

infinite time slice. All registers except for the PC and stack pointer are 

undefined. The initial process stack is provided from the NX 200 data area and 

is guaranteed to be at least 100H bytes deep. The process is free to switch to a 

bigger stack if desired. In all other respects, it is a normal process, as defined 

in Section 7.5. 

Figure 4-9 shows the format of the start execution request/reply message, and 

the following paragraphs describe the individual fields in detail. 

4.9.2.1. Reserved Field 

The first field is reserved for use by NX 200, and must be initialized as 0. Its 
value in the reply message is undefined. 

4.9.2.2. User Id Code Field 

The user id code field is not interpreted by the EXOS 203, and is returned 
unmodified in the reply message. It can be used to establish a correspondence 
between request and reply messages. 

4.9.2.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 2. This value is preserved in the reply message. 
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# Length Offset Field Name 



1) 2 



2) 4 



3) 1 6 
4)1 7 
5)4 8 



Reserved for NX Usage 
User Id Code 

Request Code 
Return Code 
Starting Ad dress 



\< 1 by te- - 

Figure 4-9: EXOS 203 Start-Execution Request/Reply Message 



4.9.2.4. Return Code Field 



Request Reply 



zero 



unde f i ned 



unde f i ned p reserved 



02H preserved 

undef i ned see text 
see text prese r ved 



The reply code field is undefined in the request message. In the reply message, 
it reports the status of the start execution request. 

Successful completion. 

A2H Invalid starting address, execution not started. 

A1H Invalid request, the EXOS 203 is not in front end mode. 

4.9.2.5. Starting Address Field 

The starting address field specifies the initial value of the initial process's 
program counter. This must be a segmented address. Its value is preserved in 
the reply message. 
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Chapter 5 

INITIALIZATION AND HOST INTERFACE 

FOR UNIBUS SYSTEMS 



5.1. INTRODUCTION 



The EXOS 204 Intelligent Ethernet Controller is specifically designed for use in a 
UNIBUS system. This section contains information pertinent to the design of 
host-resident software, such as an I/O driver, which communicates with the 
EXOS 204 intelligent Ethernet controller installed in a UNIBUS-based system. 

Note that EXOS Intelligent Ethernet Controllers are available for use in different 
computer buses, such as, Multibus, Q-bus, UNIBUS, VMEbus, and PC bus. 
While logically the NX 200 operating system functions remain the same, the 
specific procedures for initialization vary for different EXOS-to-host 
combinations. 

The host interface can be broken down into two aspects, the initialization 
procedure, and the communication method subsequently used. Initialization 
refers to the process which begins upon resetting the EXOS 204, and concludes 
either with entering the Link Level Controller mode, or with the execution of 
downloaded software. During the process of initialization, the host system sets 
up the host message queue data structures. The host message queue protocol, 
defined by NX 200 firmware, uses these queues for all further communications 
between the host processor and NX 200. 

The following paragraphs give an overview of the initialization process: 

1. The host system resets the EXOS 204, then NX 200 executes self- 
diagnostics which exercise various board components and 
functions. If the diagnostics fail, then the EXOS 204 displays an 
error code on the NX 200 status LED (see Appendix A; Self- 
Diagnostic and Configuration Errors) until the board is reset again. 
If the diagnostics pass, then the EXOS 204 awaits configuration by 
the host. 

2. The host system passes NX 200 the address of a configuration 
message in host memory. The EXOS 204 examines this message, 
and modifies some fields according to the results of configuration. 
If configuration is unsuccessful, the EXOS 204 again displays an 
error code on the NX 200 status LED until reset. If the 
configuration message is valid, the EXOS 204 enters one of three 
modes, as specified by the message's operation mode field. 

3. Initialization for each of the three different modes proceeds as 
follows: 

a. In Link Level Controller Mode, the EXOS 204 begins to execute 
firmware which brings NX 200's Ethernet Data Link driver 
interface out to the host system interface. No software is 
downloaded; instead the host system passes Data Link 
commands to the board, and receives replies, through the 
standard host message queue protocol. This mode is 
described fully in Section 6. 
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b. In Front-End Mode 1, the host system proceeds to download 
software to the EXOS 204, by passing download request 
messages through the standard host message queue protocol. 
When the software has been downloaded, it passes an execute 
request to the board, which then begins to execute the 
downloaded software. Subsequent actions depend entirely on 
the software which has been installed, although the host 
message queue protocol remains in place. 

c. In Front-End Mode 2, the EXOS 204 proceeds to bootstrap 
itself from the bootstrap server configures NX 200, it may still 
communicate with the host system through the standard host 
message queue protocol. Network bootstrap is quite similar in 
many ways to initialization by a host processor; the 
configuration message described in this section is exactly 
identical. 

5.2. HARDWARE COMMUNICATIONS CHANNELS 

Communication between the host processor and the EXOS 204 is conducted via 
a coordinated exchange of interrupts, I/O instructions, and data transfers 
through shared memory on the UNIBUS. The following sections define these 
primitive channels of communication which are used during the process of 
initialization and, subsequently, to implement the message queue protocol. 

5.2.1. Host Access to the EXOS 204 UNIBUS Board 

The host's means of active access to the EXOS 204 are solely through two I/O 
ports, named port A and port B here for the sake of reference. These ports are 
accessed over the UNIBUS, and can be both read and written. Their addresses 
are selected by jumpers on the EXOS 204, described in the EXOS Intelligent 
Ethernet Controller Reference Manual. 

The effects of reading and writing ports A and B are summarized below: 



Read A 
Write A 
Read B 



No Operation. 

Resets the EXOS 204 (refer to Section 5.4). 

Returns the EXOS 204 status byte: 

Bit 0: (Error Bit) when 0, indicates a fatal error in 

EXOS 204. When the EXOS 204 is reset, this 
bit is 0, but will be set to 1 if the self test 
completes successfully. If this bit is not set 
within 3 seconds, then the EXOS 204 has 
failed the self-diagnostics. 

Bits 1-2: Undefined. 

Bit 3: (Ready Bit) when 0, indicates that NX 200 is 

ready to accept a byte written into port B. 
When 1 , NX 200 has not yet read the byte last 
written into port B. 

Bits 4-5: Undefined. 
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Bit 6: (Loopback Test Bit) when 0, indicates loopback 

test passed. When 1, indicates loopback test 
failed, possibly due to faulty transceiver or 
faulty transceiver cable. 

Bit 7: Undefined. 

Write B: Interrupts the EXOS 204 CPU, and communicates a 1-byte 
value. This is the only way to communicate a value to the 
EXOS 204 other than through shared memory. 

5.2.2. EXOS 204 UNIBUS Board Access to the Host 

The EXOS 204 functions as a master on a UNIBUS system. It can access the 
full 256-Kbyte memory address space which includes the 8K I/O address 
space, and interrupt the host processor. User software on the EXOS 204 does 
not directly control these resources. Instead, it calls NX 200's host interface 
driver, described in Section 9 

In general, data is transferred between the host and the EXOS 204 via shared 
memory, which may be any portion of system memory accessible to both 
processors on the UNIBUS. The EXOS 204's CPU performs the transfer by 
dynamically mapping part of its own address space into the UNIBUS memory 
address space, and executing a block transfer instruction. Note that the EXOS 
204's on-board memory cannot be shared; it is not directly accessible by the 
host processor. 

The EXOS 204 can interrupt the host either through memory addresses or the 
UNIBUS interrupt lines. The type which will be used is selected at 
initialization time. Memory interrupt addresses are configured by software; the 
interrupt line is selectable by means of a jumper option, described in the EXOS 
Intelligent Ethernet Controller Reference Manual. 

5.3. HOST DATA ORDER CONVERSION OPTION 

The host data order conversion option determines whether NX 200 will interpret 
data read from host memory according to its own native ordering, or according 
to the host CPU's native ordering. This option is selected by a field in the 
configuration message (refer to Section 5.5.5). If enabled, then the NX 200 
inspects a known data pattern in the configuration message, written in the host 
CPU's native order. It determines what conversions are necessary to make this 
pattern appear in the order it expects, for several different data types: byte 
array, word array, and longword. NX 200 will then apply the appropriate 
conversion to all data objects subsequently read from host memory. 

For the word data type, NX 200 can swap bytes if necessary. For the longword 
data type, NX 200 can swap words, swap bytes, or both. Therefore I/O driver 
software for any reasonably normal host CPU can store data objects in its native 
order, and leave conversion up to NX 200. 

Naturally, NX 200 must know the type of a data object to apply the appropriate 
conversion. All data objects described in this section are known to NX 200, 
except for the actual contents of messages between the host and the EXOS 
204. NX 200 does apply the byte array conversion (if necessary) to message 
contents, and to all data transferred. How the contents of messages should be 
further interpreted is the function of user-level software running on the EXOS 
204. For instance, the firmware which drives the Link Level Controller Mode 
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# Length Offset Sub-Field Name 



D 1 

2) 1 

3) 1 

4) 1 

5) 2 

6) 2 

7) 4 

8) 20 
Figure 5-1 : 



I Byte 
I Byte 1 



Byte 2 
By te 3 
Word 



! Word 1 



Longwo rd 



Re s e r v e d 



|< 1 byte 

Host Data Order Conversion Option Test Pattern 



Va I ue 

I 01H 

I 03H 

I 07H 

I OFH 

I 0103H 

I 070FH 

I 0103070FH 



ze ro 



(refer to Section 6) runs at user level under NX 200, and converts word and 
longword data objects which are known to itself, but not to NX 200. NX 200 
assists this process by providing kernel calls (refer to Section 9.5) which convert 
word and longword data types as required by the host data order conversion 
option. 

Whether or not the host data order conversion option is enabled, the host 
system must still write the required data pattern in the configuration message. 
This pattern occupies 12 bytes of the 32-byte test pattern/memory map field 
(refer to Section 5.5.10). It should be initialized as shown in Figure 5-1. Note 
that while the relative position of subfields in the test pattern is specified, the 
order of bytes within those subfields is dependent on the host CPU architecture. 
Figure 5-2 shows how this pattern might be initialized in the C language, both 
statically and dynamically. 

Note that memory addresses, regardless of the host address mode, are stored 
and interpreted as the longword data type. For instance, the longword test 
pattern can also be regarded as a memory address in the host's native format 
for the absolute address 0103070FH (if absolute address mode is selected) or 
for segment 070FH, offset 0103H (if segmented mode is selected). 

If NX 200 cannot make any sense of the test pattern presented by the host, 
then initialization is aborted, and the appropriate error code displayed on the 
status LED. For error code value assignments, see Appendix A; Self- 
Diagnostics and Configuration Errors. 
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I" constants for test pattern 7 
#define BYTEO 0x01 
#define BYTE1 0x03 
#define BYTE2 0x07 
#define BYTE3 OxOF 
#define WORDO 0x0103 
#define WORD1 0x070F 
#define DWORD 0x01 03070 F 

/* static initialization of test pattern 7 
struct tstptrn j 

char byteptrn[4]; 

short wordptm[2]; 

long Iwordptm; 

char rsrvd[20|; 



struct tstptrn tp = { 

BYTEO, BYTE1, BYTE2, BYTE3, 
WORDO, WORD1 , 
DWORD, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 

}; 

/" dynamic initialization of test pattern 7 
initptrn () 

{ 

register int i; 
tp.byteptrn[0] = BYTEO; 
tp.byteptrn[1] = BYTE1; 
tp.byteptm[2] = BYTE2; 
tp.byteptrn[3) = BYTE3; 
tp.wordptm[0] = WORDO; 
tp.wordptrn[1] = WORD1; 
tp.lwordptrn = DWORD; 
for (i=0; i<20; i++) tp.rsrvd[i] = 0; 



Figure 5-2: Host Data Format Test Pattern Initialization 



5.4. RESET AND CONFIGURATION PROCEDURE 

This section describes initialization by a host system up to the completion of 
configuration. Figure 5-3 shows a typical procedure which implements as much. 

The EXOS 204 is reset by the UNIBUS INIT signal, or whenever port A is 
written from the UNIBUS. Host software should use the latter method to be 
sure. On reset NX 200 performs a Series of self tests to confirm hardware 
integrity. While these tests run, the NX 200 status LED (see the EXOS 
Intelligent Ethernet Controller Reference Manual) will remain lit constantly. 
When self-diagnostics complete successfully, NX 200 sets the error bit in I/O 
port B and flashes the status LED at regular intervals. 
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extern read port(PorLNum) /* returns value read from port Port_Num V 
extern write_.port(Port_Num, Val) <* writes Val to port Port_Num */ 
extern start j;lock() ," starts an interval timer V 
extern clock() /' returns the current value of the interval timer 7 

/" bit value definitions for status byte read from port B V 
#define ERROR _BIT 1 
#define READY^BIT 8 
#define ERRNON 

struct i .-" configuration message */ 

short reserved; 

char version[4]; 

char comp_code; 
<etc ...> 
} init_msg; 

char iniLaddrs[8) = (OxFF, OxFF, 0, 0, - absolute address of init msg> 
/" refer to Section 1 for absolute address format V 

initialize () I 

< set up init_msg and the message queues (refer to Section 5.6) > 

write-port(A); /* reset the EXOS 204 7 

start _clock(); /* start timer, clock counts real time 7 

/* wait until self test completes 7 
while ((read_port(B) & ERROR_BIT) == ) ( 
if (clock() > 2_SECONDS) ( 
return (malfunctioning_board); 

i 

I 

/* write the configuration message address 7 
for (i=0; i<8; i++) { 

while (read_port(B) & READY_.BIT); 

write _port(B,init_addrs[i]); 



r wait for the reply message 7 

while (init_msg.comp_code = = OxFF); 

/" ensure no errors 7 

if (init_msg.comp_code != ERRNON) 

return (error); 
else 

return (success); 



F : igure 5-3: Typical Reset and Configuration Procedure 



If the error bit is not set within 3 seconds of reset, the host may assume that 
self-diagnostics turned up a problem. In this case, the EXOS 204 repeatedly 
reports an error code through the NX 200 status LED (for error code values, see 
Appendix A; of this manual or the EXOS Intelligent Ethernet Controller 
Reference Manual). The EXOS 204 will remain in this state until reset again. 

A jumper option, described in the EXOS Intelligent Ethernet Controller 
Reference Manual, determines how initialization will proceed after reset and 
self-diagnostics. If the jumper selects network bootstrap, then the EXOS 204 
will attempt to download software over the Ethernet (refer to Section 11.7). 
Otherwise the EXOS 204 awaits configuration by the host processor. 
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The host configures the EXOS 204 by passing it the address of a configuration 
message, located in shared memory. This message establishes various NX 200 
parameters and selects among several modes of operation. Parameters include 
memory allocation for NX 200 objects, the address of NX 200's movable data 
area in EXOS 204 memory, and the location of message queues in shared 
memory. Among the optional operation modes, the host can select network 
bootstrap. This will proceed as though the net boot jumper option had been 
installed, except that NX 200 will first note the contents of the host configuration 
message. Other configuration options include host data order conversion and 
the host address mode. 

The host processor communicates the address of the configuration message to 
NX 200 by writing a sequence of 8 bytes into port B. Each byte should be 
written after checking that the ready bit of the EXOS 204's port B is clear. This 
ensures that NX 200 is ready to accept the next address byte. The first four 
bytes of the sequence must be FF-FF-00-00 (sent from left to right). The next 
four bytes are the configuration message's absolute UNIBUS memory address 
(least significant byte first). The configuration message must be aligned on a 
even address boundary. When the last byte is written, NX 200 reads and 
interprets the configuration message. If the address for the initialization 
message is not valid, then the EXOS 204 will display an error code on the status 
LED (see the EXOS Intelligent Ethernet Controller Reference Manual). 

When NX 200 has finished processing the configuration message, it writes a 
completion code into the appropriate field of the message. Any value other than 
0FFH indicates completion; the value indicates successful configuration. 
Other values denote specific errors in configuration (refer to Section 5.5.3). 
Normally, configuration should complete within 3 seconds, but network bootstrap 
might take longer, depending on circumstance. NX 200 also returns a few 
parameters to the host in the configuration message, notably its version number 
and a map of available memory. 

Once configuration is complete, the memory space occupied by the 
configuration message can be used for any other purpose. After configuration, 
communication between the host and NX 200 is carried out solely by means of 
message queues, described in Section 5.5. 

5.5. CONFIGURATION MESSAGE FORMAT 

Figure 5-4 shows the format of the configuration request/reply message. This is 
used identically by either a host system or a network bootstrap server. The 
following paragraphs explain the individual fields in detail. Note that reply values 
other than the completion code field itself are defined only if configuration is 
successful. 

5.5.1. Reserved Field 

The first field is reserved for use by NX 200. Its value in the request message 
must be 1, and its return value is undefined. 

5.5.2. EXOS Version Code Field 

The EXOS version code field is undefined in the request message. In the reply 
message, it returns version codes for NX 200 and the EXOS 204 in the form 
X.Y and A.B, respectively. These are expressed as ASCII digits, one per byte 
in the order X-Y-A-B, starting from the lower address. 
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continued on next page 
Figure 5-4: Configuration Request/Reply Message 
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Request Reply 
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I < 1 byte-- 

Figure 5-4a: Configuration Request/Reply Message (continued) 



5.5.3. Configuration Completion Code Field 

The completion code field must be OFFH in the request message. The EXOS 
204 signals that configuration is complete, and returns the completion code, by 
writing one of the following codes into this field: 
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OOH Successful completion. 

A4H Invalid operation mode. 

ASH Invalid host data format test pattern. This occurs when NX 200 
cannot find any reasonable conversion to derive the expected 
data pattern from that supplied in the test pattern. In practice, 
this might imply that the host has given NX 200 the wrong 
address for the configuration message. 

A7H Invalid configuration message format. This may occur if 
reserved fields contain an improper value. In practice, this error 
message may indicate that the host has given NX 200 the 
wrong address for the configuration message. 

ASH Invalid movable block address. 

A9H Invalid number of processes. 

AAH Invalid number of mailboxes. 

ABH Invalid number of address slots. 

ACH Invalid number of hosts. 

ADH Invalid host message queue parameter. NX 200 returns this 
error if it detects any inconsistency in the message queue 
specifications. This might include a bad interrupt type, invalid 
segment address, bad linking of the message queue buffers, 
etc. 

AEH Insufficient memory for movable data block. 

AFH Net boot failed. 

The codes defined above will also be displayed on the status LED if 
configuration is not successful. 

5.5.4. NX 200 Operation Mode Field 

NX 200 operation mode field determines the mode in which the EXOS 204 is to 
be used. Three different modes are supported: 

Link Level Controller Mode. This mode brings the Ethernet Data 
Link interface out to the host interface. No software is 
downloaded. It would typically be used when the EXOS 204 is 
substituted for the traditional non-programmable Ethernet 
controller board. For details, refer to Section 6. 

1 Front-End Mode, download from the host. In this mode the 
EXOS 204 is used as a front-end processor. Higher level 
software is downloaded by the host. 

2 Front-End Mode, download from the net. In this mode the 
EXOS 204 is used as a front-end processor and higher level 
software is downloaded from the network. For details, refer to 
Section 1 1 . 

All other values for the mode are reserved and their effects are not defined. If 
NX 200 is already in the process of network bootstrap (meaning that the 
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configuration message has been received from a bootstrap server) then only 
mode 2 is permitted. 

5.5.5. Host Data Order Option Field 

The host data order option field enables the host data order conversion option 
(refer to Section 5.3). Because the byte order of the host CPU will not be 
known before initialization, this field is actually treated as two one-byte fields. 
The host should load the same value into each sub-field in the request 
message. This value is defined bitwise: 

Bit 0: Deduce Format Bit. If 0, NX 200 will apply the conversions 

currently in force. If the board has not been previously 
configured, then the default conversion will be in force, 
meaning that no format conversions are applied to data read 
from the host. If this bit is 1, then NX 200 examines a 
constant data pattern written by the host in the configuration 
message's test pattern/memory map field, and deduces what 
format conversion are necessary to interpret various data 
types stored in the host CPU's native format. 

Bits 1 -7: Reserved. These bits must be in the request message. 

When initialized, NX 200 examines this field first, and interprets all other fields in 
the configuration message accordingly. This field is undefined in the 
reply message. 

5.5.6. EXOS Context 

This 3-byte field returns the EXOS context information. In the request message 
the value of this field must be zero. In the reply message, the middle byte 
(offset 11) returns the context value; the other two bytes are undefined. For the 
EXOS 204 the context value must be 04. 

5.5.7. Host Address Mode Field 

The host address mode field determines how NX 200 will interpret addresses 
which refer to objects in host memory. It is defined bitwise: 

Bit 0: Set Mode Bit. If 0, NX 200 will use the address mode 

currently in force. If the board has not been previously 
configured, then the default mode will be in force, meaning 
that NX 200 will interpret all addresses as 80186-style 
segmented addresses. If this bit is 1, then the next bit 
determines the new address mode. 

Bit 1 : Address Mode Bit. The value selects segmented address 

mode. The value 1 selects absolute address mode. 

Bits 2-7: Reserved. These bits must be zero in the request message. 

This field is undefined in the reply message. 

5.5.8. Reserved Field 

This field is reserved for future use. Its value in the request message must be 
0. Its value in the reply message is undefined. 
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5.5.9. Memory Map Size Field 

The memory map size field must be in the request message. In the reply 
message, it returns the number of segments available in EXOS 204 memory for 
user software. This field contains a valid value only if the EXOS 204 is 
configured in mode 1 or mode 2. 

5.5.10. Test Pattern/Memory Map Field and Maximum Packet Size 

The test pattern/memory map field serves different purposes in the request and 
reply messages. In the request message, it must contain the test pattern 
described in Section 5.3, stored in the host CPU's native format. 

In the reply message, the test pattern/memory map field contains a map of 
memory available for user software on the EXOS 204. This map consists of up 
to 4 segment descriptors, where the actual number is indicated by the last field. 
Each segment descriptor specifies a memory segment in terms of the lowest 
address and the highest address included within the segment. Each address is 
four bytes long, in the segmented format. The lower bound is given first, then 
the upper bound. This field contains a valid value only if NX 200 is configured in 
mode 1 or mode 2. If the optional 128K of RAM between 20000H and 3FFFFH 
is either absent or is malfunctioning, then the map will not contain this segment. 

5.5.11. NX 200 Movable Block Address Field 

The NX 200 movable block address field can be used to redefine the location of 
NX 200's movable data area, described in Section 7.3. If the EXOS 204 is 
configured in mode 0, this field must be 0FFFFH, 0FFFFH. In modes 1 or 2, the 
value 0FFFFH, 0FFFFH specifies that the default location be used. If a non- 
default address is specified, the segment base must be 0. The offset must 
place the entire block either between 200H and 3FFH, or between 1000H 
and 0FFFFH. 

In the reply message, this field returns the actual address of the NX 200 
movable data area. The reply value is not defined in mode 0. 

5.5.12. Number of Processes Field 

The number of processes field configures the maximum number of processes 
which NX 200 will support. If the EXOS 204 is configured in mode 0, this field 
must be 0FFH. In modes 1 or 2, the value 0FFH specifies that the current value 
be used. The default value, after reset, is 12. Optionally, a value between 1 
and 128 can be specified. In the reply message, this field returns the actual 
number of processes which NX 200 will support. The reply value is not defined 
in mode 0. 

5.5.13. Number of Mailboxes Field 

The number of mailboxes field configures the maximum number of mailboxes 
which NX 200 will support. Note that this number does not include system 
mailboxes. If the EXOS 204 is configured in mode 0, this field must be 0FFH. 
In modes 1 or 2, the value 0FFH specifies that the current value be used. The 
default value, after reset, is 16. Optionally, a value between 1 and 128 can be 
specified. In the reply message, this field returns the actual number of 
mailboxes which NX 200 will support. The reply value is not defined in mode 0. 
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5.5.14. Number of Multicast Slots Field 

The number of multicast slots field configures the maximum number of multicast 
address slots which NX 200 will support. Note that this number does not include 
the physical, broadcast, universal, or null slots, which are permanently allocated. 
The value OFFH specifies that the current value be used. The default value, 
after reset, is 8. Optionally, a value between and 252 can be specified. In the 
reply message, this field returns the actual number of address slots which NX 
200 will support. 

5.5.15. Number of Hosts Field 

The number of hosts field specifies the number of host CPUs on the UNIBUS 
interface. Permissible values depend on the mode of operation. In all modes, 
the value OFFH will retain the value currently in force. Upon first configuration, 
the default value is 0. In operation modes and 1, only the value 1 may be 
specified. However in mode 2 (network bootstrap), this field can be either or 
1. If 0, then the host message queues are undefined and the configuration 
message fields pertaining to them will not be examined. Its value is preserved 
in the reply message. 

5.5.16. Host-to-EXOS Message Queue Base Address Field 

The host-to-EXOS message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from the host to the EXOS 204 (refer to Section 5.6). 
Addresses for all message queue data structures are 16-bit offsets, calculated 
relative to this base. NX 200's interpretation of this base address depends on 
the host address mode selected (refer to Sections 1 and 5.5.7). 

In segmented mode, this field must contain an 8086-style segmented address, 
stored according to the convention described for the longword data type (lower- 
order 16 bits contain the offset, higher-order 16 bits contain the segment). The 
offset value of this address must be 0; therefore the segment begins on some 
even 16-byte address boundary. 

In absolute mode this field contains a 18-bit absolute memory address, also 
stored as a longword. The lower-order 18 bits contain the address; the 
remaining high-order 14 bits are reserved and must be 0. Furthermore, the 
lower-order 4 bits of the address must also be 0, so that the segment begins on 
some even 16-byte address boundary. 

This field's value is preserved in the reply message. 

5.5.17. Host-to-EXOS Message Queue Header Address Field 

The host-to-EXOS message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the host-to-EXOS message queue. Its value in the reply message 
is preserved. 
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5.5.18. Host-to-EXOS Message Queue Interrupt Type Field 

The host-to-EXOS message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
Host-to-EXOS 204 message queue. Options are: 

No interrupt. The host polls the message queues. 

1 Undefined. 

2 Memory mapped. The EXOS 204 writes a specified value at the 
specified memory address. 

3 Undefined. 

4 Bus-vectored interrupt. 

The value of this field is preserved in the reply message. 

5.5.19. Host-to-EXOS Message Queue Interrupt Value Field 

The host-to-EXOS message queue interrupt value field is defined only for 
memory mapped interrupt type. If interrupt type 2 is selected, then this value 
will be written to the specified memory address when an interrupt is asserted. 
The value of this field is preserved in the reply message. 

5.5.20. Host-to-EXOS Message Queue Interrupt Address Field 

The host-to-EXOS message queue interrupt address field is defined only 
memory mapped and bus-vectored interrupt type. If interrupt type 2 is selected, 
then it contains a UNIBUS memory address, which NX 200 will interpret 
according to the host address mode. If interrupt type 4 is selected, then the first 
word contains an interrupt vector; contents of the second word are undefined. 
The value of this field is preserved in the reply message. 

5.5.21. EXOS-to-Host Message Queue Base Address Field 

The EXOS-to-host message queue base address field specifies the base 
address of the shared memory which contains the queue data structures for 
transferring messages from NX 200 to the host (refer to Section 5.6). This is 
exactly equivalent to the host-to-EXOS message queue base address field (refer 
to Section 5.5.16). Its value in the reply message is preserved. 

5.5.22. EXOS-to-Host Message Queue Header Address Field 

The EXOS-to-host message queue header address field specifies the offset of 
the queue header. This offset must be calculated relative to the base address 
specified for the EXOS-to-host message queue. Its value in the reply message 
is preserved. 

5.5.23. EXOS-to-Host Message Queue Interrupt Type Field 

The EXOS-to-host message queue interrupt type field specifies the type of 
interrupt which NX 200 will use to alert the host of a change in the status of the 
EXOS 204-to-host message queue. Options are: 

No interrupt. The host polls the message queues. 
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1 Undefined. 

2 Memory mapped. The EXOS 204 writes a specified value at the 
specified memory address. 

3 Undefined. 

4 Bus-vectored interrupts. 

The value of this field is preserved in the reply message. 

5.5.24. EXOS-to-Host Message Queue Interrupt Value Field 

The EXOS-to-host message queue interrupt value field is defined only for 
memory mapped interrupt type. If interrupt type 2 is selected, then this value 
will be written to the specified memory address when an interrupt is asserted. 
The value of this field is preserved in the reply message. 

5.5.25. EXOS-to-Host Message Queue Interrupt Address Field 

The EXOS-to-host message queue interrupt address field is defined only for 
memory mapped and bus-vectored interrupt types. If interrupt type 2 is 
selected, then it contains a UNIBUS memory address, which NX 200 will 
interpret according to the host address mode. If interrupt type 4 is selected, 
then the first word contains an interrupt vector; contents of the second word 
are undefined. The value of this field is preserved in the reply message. 

5.6. MESSAGE QUEUE FORMAT 

Once the EXOS 204 is configured, message queues in shared memory serve all 
further communications with the host. This includes software download, link 
level controller mode service requests, and communication with downloaded 
protocol code. Two message queues are maintained by the NX 200 firmware, 
one for each direction of transfer. This section describes the format of the data 
structures which compose a message queue. Following sections describe how 
these must be initialized, and then the protocol which ensues after configuration. 

Each message queue necessarily includes one queue header and a singly- 
linked, circular list of message buffers. The required queue header belongs to 
NX 200; it reads and modifies its value during message exchange. The host 
may read it, but must not modify it. The EXOS 204 queue header and all 
message buffers must lie within a single 64K area of memory, called the queue 
segment. 

Message queue data structures are described here as viewed by NX 200. The 
configuration message provides NX 200 with the queue segment base and the 
offset address of the queue header, for each queue. NX 200 regards the queue 
header value and link field values as 16-bit offsets calculated relative to the 
queue segment base. As long as this view is preserved for NX 200, users are 
perfectly free to augment these data structures in any manner necessary to 
implement the desired mechanisms for the host message handling software. 

Figure 5-5 shows the format of a message buffer, and the following paragraphs 
describe the individual fields in detail. 
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5.6.1. Link Field 

The link field is the address of the next buffer in the circular queue. This 
address must be an offset calculated relative to the queue segment base 
specified in the configuration message. This field is static and should not be 
changed after configuration. 

5.6.2. Reserved Field 

This field is reserved. It must be initialized with the value 0, and set to in 
Host-to-EXOS messages. Its value in reply message is undefined. 



Length Offset 



Field Name 



1) 



2) 


1 


2 


3) 


1 


3 


4) 


2 


4 



5) n 



Link 



Rese r ved 



Status 
Leng t h 



Data 



■ 1 byte- 



Figure 5-5: Message Buffer Format 



5.6.3. Status Field 



The status field is used to implement the message protocol, and is defined bit by 
bit: 

Bit 0: Owner bit. If then the buffer is owned by the host; if 1 then 

the buffer is owned by NX 200. The host may alter a 
message buffer only while it has ownership. 

Bit 1 : Done bit. The EXOS 204 sets this to along with the owner 

bit every time it passes a buffer to the host. Host software 
can use the done bit to distinguish between buffers newly 
received from NX 200 and buffers it has already processed. 

Bit 2: Overflow Bit. The EXOS 204 sets this bit to 1 if an EXOS- 

to-Host message had to be truncated because the host 
buffer's Data Field was shorter than the message sent. 

Bits 3-7: Undefined. These bits are reserved for NX 200, and should 
not be used for any purpose by the host. 
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5.6.4. Length Field 



The length field specifies the number of bytes in the data field. The maximum 
length of the data field is a matter of agreement between the host and the user 
software on the EXOS 204. There is no restriction on the size of the data field 
as long as the buffers satisfy the queue segment constraints. Most applications 
will transfer small amounts of control information via messages, and use direct 
memory access to move larger data buffers. 

In Host-to-EXOS messages, set this field's value before passing the message to 
NX 200. In EXOS-to-Host messages, this field tells the host how many valid 
bytes were written into the data field. The host must reset its value to the data 
field's size before returning a buffer to NX 200. 

5.6.5. Data Field 

The data field contains the actual message data passed between the host and 
the EXOS 204. NX 200 does not interpret its contents in any way - it is exactly 
equivalent to the data field in messages as seen by processes on the EXOS 204 
(refer to Section 7). 

5.7. MESSAGE QUEUE INITIALIZATION 

The host must initialize the message queues and the queue headers prior to 
configuring NX 200. Figure 5-6 shows the relation between queue headers and 
message queue buffers at initialization time for a typical implementation. In 
each queue, the host and EXOS 204 queue headers should point to the 
same buffer. 

For each queue, the link fields should be initialized to form a circular, singly- 
linked list. This ring structure should not be modified after configuration. Each 
queue may contain an arbitrary number of buffers, so long as at least one is 
supplied. The reserved field of all message buffers in both queues should be 
set to 0. 

In the host-to-EXOS queue the status field of all buffers should contain the value 
02H, which indicates that they are owned by the host. The length and data 
fields are not defined at initialization. 

In the EXOS-to-host queue the status field of all buffers should contain the value 
03H, which indicates that they are owned by NX 200. The length field of each 
buffer should not exceed the size of the data buffer. Note that the length field 
must be initialized to accommodate the length of the largest message expected 
from NX 200, or the message will be truncated upon reception. The data field is 
not defined at initialization. 

Figure 5-7 is a snapshot of an example EXOS-to-host message buffer queue at 
the time of initialization. This example assumes a PDP-11 host system, where 
the EXOS 204 is configured in the segmented host address mode. The 
configuration message describing the queue is also shown in part. Data 
structures are shown as vectors containing hexadecimal byte values. The 
UNIBUS physical address of each data structure is shown to the left (slightly 
above the location), and its name to the right. According to the configuration 
message in this example, writing the value 40H at memory location 1board4H 
will interrupt the host. NX 200 will assert this interrupt when the status of the 
EXOS-to-host message queue changes, as described in the following section. 
The circular message queue shown here contains three buffers of equal length, 
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Figure 5-6: Message Queue Data Structures at Initialization Time 



each providing a 32-byte data field. The queue header points to one of the 
buffers, arbitrarily chosen, at its link field address. 

5.8. MESSAGE QUEUE PROTOCOL 

This section describes the protocol which NX 200 follows in sending messages 
to, and receiving messages from, the host processor. As it happens, host 
software can follow the same procedure, so that the exchange is symmetrically 
defined. The description below assumes such an implementation, but certainly 
other methods are possible, within the constraints of NX 200s behavior. 

In a typical implementation, the host system and NX 200 each maintain private 
queue headers for both queues (see Figure 5-6). NX 200's host-to-EXOS 
message queue's header points to the message buffer which NX 200 will 
receive next. NX 200's EXOS-to-host message queue's header points to the 
message buffer which NX 200 will send to next. NX 200 maintains these queue 
headers after configuration. Although NX 200's queue headers are kept in host 
memory, after initialization the host should not refer to these. Similarly, NX 200 
will not refer to the host's own queue headers. Host queue headers may be of 
any format (16-bit offset, 32-bit virtual address, array index.etc.) which is most 
convenient to the host software. 

For the host-to-EXOS queue, the host's queue header should always point to 
the next buffer in which the host will send a message. NX 200's queue header 
will always point to the next buffer in which NX 200 will look for a message. 
Both pointers will always move sequentially through the message queue. Note 
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Figure 5-7: Example EXOS-to-Host Message Queue, at Initialization 
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that unless a message arrives on the next buffer, NX 200 will not scan any 
further in the queue. This means that the host should always write the message 
in the next buffer where NX 200 expects it to be rather than in any arbitrary 
position in the queue. During the course of message processing, the host's 
queue header may end up several buffers ahead of NX 200's queue header, but 
should never "lap" it from behind. Any difference between the headers 
represents buffers which NX 200 has not yet consumed. 

For the EXOS-to-host queue, the host's queue header should always point to 
the next buffer in which the host will look for a message. NX 200's queue 
header will always point to the next buffer in which NX 200 will send a message. 
As above, both pointers will always move sequentially through the message 
queue. Note that unless the next buffer is available to NX 200, it will not scan 
any further to find a free buffer to write the message. This means that NX 200 
will always write the message in the next buffer where the host expects it to be 
rather than in any arbitrary position in the queue. During the course of message 
processing, NX 200's queue header may end up several buffers ahead of the 
host's queue header, but again, should never "lap" it from behind. Any 
difference between the headers represents buffers which the host has not yet 
consumed. 

5. 8. 1 . Host-to-EXOS Message Transfer 

Host software can transfer messages to NX 200 using the following steps: 

1. Test, the owner bit of the buffer to which the host queue header 
points. If NX 200 still owns this buffer, then wait until it is returned 
(either poll the owner bit, or wait for the interrupt which 
accompanies each buffer turnover event). 

2. Advance the host queue header, so that it now points to the next 
buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field appropriately. 

4. Set the current buffer's owner bit, so that the buffer now belongs to 
NX 200. 

5. Interrupt NX 200 by writing to port B, to notify it that a new 
message is available. 

The EXOS 204 can process more than one message from the host upon 
receiving a single interrupt. Therefore it is important that the host change the 
buffer's owner bit only after preparing the other fields. Otherwise, if NX 200 is 
still processing a previous interrupt from the host, it may consume a half-baked 
message. Note that the host may prepare more than one message buffer at a 
time, and send a single interrupt, if sufficient buffers are available. 

When NX 200 receives an interrupt from the host, it will: 

1 . Examine the owner bit of the buffer to which its own queue header 
points. If the buffer belongs to NX 200, then it will process it, as 
described in the following steps. (Otherwise, the interrupt could 
mean that the host is returning an EXOS-to-host message buffer, or 
could be spurious.) 
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2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Extract the message from the current buffer. If there is no 
consumer for this data (no receive request on the NX 200's host 
interface mailbox), then wait. 

4. Reset the current buffer's owner bit, so that the buffer is returned to 
the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a buffer has been returned. The 
type of interrupt is specified by the configuration message. Repeat 
from step 1, until the owner bit shows that no new messages 
are pending. 

Note that the interrupt described in step 5 is the same interrupt which the host 
waits upon when no message buffers are available. 

5.8.2. EXOS-to-Host Message Transfer 

When the EXOS 204 has a message to transfer to the host, NX 200 will: 

1 . Test the owner bit of the buffer to which its queue header points. If 
the buffer belongs to NX 200, then process it, as described in the 
following steps. Otherwise, wait for an interrupt from the host which 
indicates that a buffer has been returned (NX 200 can process 
other jobs in the mean time). 

2. Load the link field of the current buffer into its queue header, so that 
it now points to the next buffer in the queue. 

3. Load the message into the data field of the current buffer, and set 
the length field to the length actually transferred (it will not exceed 
data field length). If the data field was too short for the message, 
then it sets the overflow bit. 

4. Reset the current buffer's owner bit, so that the buffer now belongs 
to the host. Set the buffer's done bit to 0. 

5. Interrupt the host to notify it that a new message is available. The 
type of interrupt is specified by the configuration message. 

When the host receives an interrupt from NX 200, it can: 

1. Examine the owner bit of the buffer to which the host queue header 
points. If the buffer belongs to the host, then it should process it, 
as described in the following steps. (Otherwise, the interrupt could 
mean that NX 200 is returning a host-to-EXOS message buffer, or 
could be spurious.) 

2. Advance the host's own queue header, so that it now points to the 
next buffer in the queue. 

3. Extract the message from the current buffer. It may check the 
overflow bit to be certain that the entire message was sent. If there 
is no consumer for this data, then wait. 

4. Set the length field to the size of the data field. 
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5. Set the current buffer's owner bit, so that the buffer is returned to 
NX 200. 

6. Interrupt NX 200 by writing to port B, to notify it that a message 
buffer has been returned. Repeat from step 1, until the owner bit 
shows that no new messages are pending. 

While the host is processing an interrupt, NX 200 may in the meantime write 
more messages into the queue. The host may elect to process these messages 
in addition to the message associated with the interrupt being serviced. Note, 
however, that at least one interrupt will remain pending, so that when interrupts 
are re-enabled, the host will be again interrupted by NX 200, although the 
corresponding message would have already been processed. 

Although the above description assumes that the EXOS 204 is programmed to 
interrupt the host to signal message queue events, the host also has the option 
of simply polling the message queue. 

5.9. DOWNLOADING SOFTWARE FROM THE HOST 

Normally, if the EXOS 204 is configured in mode 1, host software would then 
download and run higher level protocol software. Two message formats are 
provided for this purpose, one to copy user code and data to NX 200, and 
another to start code execution. For each message NX 200 sends a 
corresponding reply message which confirms the completion of the request. 

5.9.1. Host Download Request 

The host can copy code to any location in EXOS 204 memory which is normally 
available to the user. The download request copies buffers up to 64K-1 each in 
size, in any order, without modification. NX 200 does not protect the user area 
against un-intentional overlays. Figure 5-8 shows the format of the download 
request/reply message, and the following paragraphs describe the individual 
fields in detail. 

5.9.1.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 

5.9.1.2. User Id Code Field 

The user id code field is not interpreted by the EXOS 204, and is returned 
unmodified in the reply message. It can be used to establish a correspondence 
between request and reply messages. 

5.9.1.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 0. This value is preserved in the reply message. 

5.9.1.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the download request: 

Successful completion. 
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A3H Destination memory block overlaps the memory reserved for NX 
200, no copy done. 

A1 H Invalid request, the EXOS 204 is not in front end mode. 

5.9.1.5. Data Length Field 

The data length field specifies the number of bytes to be copied into EXOS 204 
memory. This may be any value between and 64K-1. In the reply message, 
this field returns the number of bytes actually copied. 

5.9.1.6. Source Address Field 

The source address field specifies the starting address in shared memory from 
which to copy the user code image. This may be either a segmented or an 
absolute address, depending on the host address mode option. Its value in the 
reply message is undefined. 
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5.9.1.7. Destination Address Field 

The destination address field specifies the starting address in EXOS 204 
memory to which the user code image will be copied. This must be a 
segmented address. Its value in the reply message is undefined. 
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Figure 5-9: EXOS 204 Start-Execution Request/Reply Message 
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5.9.2. Start Execution Request 

After downloading protocol software, the host processor starts it executing with 
a single start execution request message. Once this command has been issued 
and the reply received, NX 200 does not itself process any more messages. 
Instead, all messages sent to the EXOS 204 will be queued up for user 
processes running under the NX 200 kernel. 

The start execution request specifies the location at which execution of user 
code begins. User code is entered as a single process with priority 255 and 
infinite time slice. All registers except for the PC and stack pointer are 
undefined. The initial process stack is provided from the NX 200 data area and 
is guaranteed to be at least 10OH bytes deep. The process is free to switch to a 
bigger stack if desired. In all other respects, it is a normal process, as defined 
in Section 7.5. 

Figure 5-9 shows the format of the start execution request/reply message, and 
the following paragraphs describe the individual fields in detail. 
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5.9.2.1. Reserved Field 

The first field is reserved for use by NX 200, and must be initialized as 0. Its 
value in the reply message is undefined. 

5.9.2.2. User Id Code Field 

The user id code field is not interpreted by the EXOS 204, and is returned 
unmodified in the reply message. It can be used to establish a correspondence 
between request and reply messages. 

5.9.2.3. Request Code Field 

The request code field defines the request. Its value in the request message 
must be 2. This value is preserved in the reply message. 

5.9.2.4. Return Code Field 

The reply code field is undefined in the request message. In the reply message, 
it reports the status of the start execution request. 

Successful completion. 

A2H Invalid starting address, execution not started. 

A1H Invalid request, the EXOS 204 is not in front end mode. 

5.9.2.5. Starting Address Field 

The starting address field specifies the initial value of the initial process's 
program counter. This must be a segmented address. Its value is preserved in 
the reply message. 
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Chapter 6 
LINK LEVEL CONTROLLER MODE 



6.1. INTRODUCTION 



In the link level controller mode, NX 200 provides a standard Ethernet Data Link 
interface to the host system. The host system selects link level controller mode 
at initialization time, by specifying operation mode in the configuration 
message (see the Configuration Message Format section of the appropriate 
INITIALIZATION and HOST INTERFACE chapter. At this time, instead of 

the host downloading protocol software, as it would in front-end processor 
mode, NX 200 runs firmware which brings NX 200s on-board Ethernet driver 
out to the host interface. The host can then access all Ethernet functions by 
exchanging request and reply messages with NX 200 via the message protocol 
described in the Configuration Message Format section of the appropriate 
INITIALIZATION and HOST INTERFACE chapter. In either case, NX 200 uses 
the EXOS Intelligent Ethernet Controller's RAM primarily to buffer packets in 
both directions between the network and the host. 

Link level controller mode functionality is very similar to the NX 200 Ethernet 
interface for EXOS 200 Series board-resident software, described in Section 8. 
Because the underlying objects and capabilities of this mode are identical, they 
will not be described here in the same detail. Instead, this section concentrates 
on the format and usage of request messages. 

6.2. THE CONTROLLER MODE INTERFACE 

After NX 200 has been initialized in mode 0, the host sends commands as 
request messages in the host-to-EXOS queue. When a request is completed, 
NX 200 places a reply message in the EXOS-to-host queue. These queues 
may be arbitrarily long, and can be used to pipeline Ethernet operations. Figure 
6-1 shows how messages are encapsulated in the message queue buffers. 

In link level controller mode, NX 200 honors six request messages: 

TRANSMIT Send packet from host memory onto Ethernet 

RECEIVE receive packet from Ethernet into host memory 

NET.MODE Read/modify the net mode 

NET_ADDRS Read/modify an address slot 

NET_RECV Enable/disable receive on an address slot 

NET_STSTCS Read/clear the network statistics 

The first two requests above correspond to the transmit and receive messages 
which on-board software would send to the Ethernet system process under 
NX 200 (see Sections 8.1 and 8.2). The latter four requests correspond exactly 
to the NX 200 calls by the same name which on-board software would use (see 
Section 10). 

Figure 6-2 conceptually shows how requests are processed by NX 200. 
According to the message queue protocol, as soon as the host software has 
placed a request message in a host-to-EXOS message queue buffer, it 
interrupts NX 200. When interrupted, NX 200 reads the requests from the 
queue and buffers them in its on-board memory. 
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Figure 6-1 : Encapsulation of Request/Reply Message in Message Buffer 



A request is said to be outstanding once it has been read from the host request 
queue, and until the corresponding reply message has been written to the host 
reply queue. NX 200 can buffer up to 32 outstanding request messages. 
Additional requests will remain in the host request queue until buffers are made 
available by request completion in NX 200. This should be noted when 
designing host software, since certain implementations could become 
deadlocked by outstanding requests. In particular, receive requests remain 
outstanding at least until a packet is received from the network. In general, no 
more than 32 receive requests should be made at any time. 

Note that in link level controller mode, NX 200 will buffer incoming packets (that 
pass address filtering) even if no receive requests have been submitted. 

As shown by Figure 6-2, NX 200 effectively places different request messages 
in separate internal queues and processes them asynchronously, according to 
their type. Network management requests are generally processed immediately, 
and transmit requests are processed as fast as the Ethernet Data Link protocol 
permits. Receive requests remain outstanding until packets arrive on the 
Ethernet, unless received packets are already buffered up in NX 200. 
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Figure 6-2: Link Level Controller Mode Request Processing Scheme 



NX 200 sends reply messages back to the host immediately upon request 
completion, not necessarily the order in which they are accepted. In order to 
ensure a specific sequence of operations among requests of different types, a 
request should be issued only after the reply message for the preceding 
operation in the sequence has been received. Each request message carries a 
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32-bit user id field, the firld is not interpreted by NX 200 and is returned 
unmodified in the reply message. This field can be used for any purpose, for 
example, to establish a correspondence between a request and its reply 
message. 

The remainder of this section specifies the format of the request/reply messages 
for each request. Where these requests map directly into NX 200 calls (see 
Section 10), the figures also mention the corresponding CPU registers, if any, in 
parentheses (request, reply). 

In addition to the error codes defined for NX 200 calls, any request may return 
the general error code 0A1H if (a) the request message is shorter than the 
specified length, (b) an invalid request code is used, or (c) NX 200 is not 
initialized in link level controller mode. 

6.3. TRANSMIT REQUEST/REPLY MESSAGE 

To transmit a packet on the Ethernet, host software sends a transmit request 
message to NX 200. This message contains pointers to an Ethernet packet in 
host memory. Packets are prepared for transmission in standard Ethernet data 
link layer frame format, as described in Section 8.1. Host software should 
prepare the address and type fields. Packets should not include preamble or 
CRC fields, which are prepared by EXOS Intelligent Ethernet Controller 
hardware. If it serves the purposes of host software, the packet may be 
composed of up to eight disjoint blocks in host memory. 

NX 200 enqueues transmit requests, and completes packet transmission without 
any intervention from the host. When NX 200 accepts a transmit request, it 
gathers the packet (or packet fragments) from host memory, and assembles the 
packet in an internal transmission buffer. Four such buffers are allocated in link 
level controller mode, and transmission requests are pipelined - if more than 
four transmit requests are pending, the packet is not necessarily read from host 
memory immediately upon acceptance of a new request. This is unlikely, unless 
the network is very heavily loaded. 

If NX 200 is in off net mode (described in Section 8.4) then transmit requests 
will be enqueued, but will remain outstanding until NX 200 is put back in an on 
net mode. If NX 200 is taken off net during a transmission, then the current 
transmission will first be completed. If the net disable option is selected (see 
Section 8.4), then transmission will appear to complete normally, but nothing is 
actually sent on the Ethernet. 

An alternate form of the transmit request is provided in link level controller mode 
only. This is transmit with self-receive, and is selected by the request code 0EH 
(instead of 0CH). When this form of the transmit request is used, transmission 
occurs just as with a normal transmit request, but also generates a received 
packet - if the destination address passes the established address filtering. 
Address filtering is performed according to normal procedure for incoming 
packets with one difference: in imperfect filtering mode, multicast packets are 
always self-received. 

Transmit requests are dispatched in the order they are received from the host 
system. When the request is completed, NX 200 modifies the request message 
according to the status of the transmission and returns it to the host as a reply 
message. Until the reply message is received through the EXOS-to-host 
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Figure 6-3: TRANSMIT Request/Reply Message 



>l 



message queue, the indicated Ethernet packet belongs to NX 200 and should 
not be modified. 

Figure 6-3 shows the format of the Ethernet transmit request/reply message, 
and the following paragraphs describe its individual fields in detail. 



6.3.1. Reserved Field 



The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 
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6.3.2. User Id Code Field 

t 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

6.3.3. Request Code Field 

The request code field defines the request: 

OCH Transmit. 

OEH Transmit with self-receive. 
This field's value is preserved in the reply message. 

6.3.4. Return Code Field 

The return code field value in undefined in the request message. In the reply 
message, it reports the status of the transmission request: 

00H Successful transmission, no retry. 

01 H Successful transmission, 1 retry. 

02H Successful transmission, more than 1 retry. 

08H (Applicable for Version 2.0 transceivers only.) Indicates the 
absence of SQE (heartbeat) TEST signal during the Innerframe 
Spacing interval. This return code is OR-able with all other 
message values except 40H and 0A1h. A jumper option is 
available to disable this check. (Refer to the appropriate EXOS 
Intelligent Controller Hardware Reference Manual) 

10H Transmission failed, excessive collisions. 

20H No Carrier Sense signal detected during transmission. 

40H Transmission failed, transmit length not in range. 

0A1H Failed, NX 200 is not in controller mode. 

6.3.5. Address Slot Field 

The address slot field is an index into the address slot array. Its value in the 
request message is undefined. In the reply message, it contains the address 
slot number by which this packet would be received by this station. For 
instance, the value 255 indicates that the packet was broadcasted, and should 
be auto-received. Or, if the packet was transmitted to this stations own address, 
the value would be 253. A zero value means that no slot matched - this packet 
would not be received by this station. 

6.3.6. Number of Data Blocks Field 

The number of data blocks field specifies the number of data length/data 
address field pairs that follow this field in the request message. Each pair 
describes one block, where a packet may occupy up to eight disjoint blocks in 
shared memory. This field's value is preserved in the reply message. 
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6.3.7. Data Block Length Field 

The data block length field specifies the length in bytes of the data block whose 
address follows. The sum of all data block length fields should be the total 
packet length. This value does not include the preamble or CRC fields, which 
are appended by EXOS Intelligent Ethernet Controller hardware. In the reply 
message, this field's value is preserved. 

6.3.8. Data Block Address Field 

The data address field specifies the address of a data block in shared memory, 
where up to eight blocks compose a packet. Note that the packet, as handed 
over to NX 200, does not include a preamble, so that the address of the first 
block will point to the first byte of the packet's destination field. The data 
address field is preserved in the reply message. 

6.4. RECEIVE REQUEST/REPLY MESSAGE 

Host software receives a packet on the Ethernet by sending an Ethernet receive 
request message to NX 200. This message contains pointers to a packet buffer 
in host memory. If NX 200 has already received a packet from the Ethernet, 
then it will copy the packet into the host buffer. Otherwise the request will not 
complete until a packet is received. 

Received packets are returned to the host in standard Ethernet data link layer 
frame format, as described in Section 8.1. Address, type, and CRC fields are 
included, but not the preamble. NX 200 performs address and CRC checks in 
hardware. If it serves the purposes of host software, the packet buffer may 
comprise up to eight disjoint blocks in host memory. 

NX 200 will receive packets from the Ethernet according to several criteria. One 
is the mode of operation, which determines whether to listen at all, and whicn 
categories of address to accept. Another factor is the address filter, which 
determines the physical address, and up to 252 active multicast addresses. The 
last factor to consider is the options mask, which defines acceptable errors m 
received packets. Subsequent sections describe these factors in more detail. 

When a packet on the Ethernet satisfies the criteria for reception, NX 200 
receives and buffers the packet in its own memory. In link level controller mode, 
the EXOS 200 Series board provides 32 full-size on-board packet buffers which 
are chained in controller hardware. Therefore it can receive 32 Ethernet packets 
back-to-back, with minimal interframe spacing, even when no receive requests 
from the host are pending. 

When reception is complete, NX 200 modifies the request message according to 
the status of the reception and returns it as a reply message. Receive requests 
are queued up and dispatched in the order received. Until the reply message is 
received through the EXOS-to-host message queue, the indicated buffer 
belongs to NX 200 and should not be used. 

Figure 6-4 shows the format of the Ethernet receive request/reply message, and 
the following paragraphs describe its individual fields in detail. 
6.4.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 
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6.4.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

6.4.3. Request Code Field 

The request code field defines the request. Its value in the Ethernet receive 
request message must be ODH. This value is preserved in the reply message. 

6.4.4. Return Code Field 

The return code field value in undefined in the request message. In the reply 
message, it reports the status of the receive request: 
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00H Packet received with no error. 

04H Packet received longer than buffer supplied, truncated. 

10H Packet received with alignment error. 

20H Packet received with CRC error, 

40H No packet received, buffer supplied was less than 64 bytes. 

0A1 H Failed, NX 200 is not in controller mode. 

Note that packets with errors are actually received only if the network mode is 
set appropriately. 

6.4.5. Address Slot Field 

The address slot field is an index into the address slot array. Its value in the 
request message is undefined. In the reply message, it contains the address 
slot number which matched the destination address of the packet received. If 
the controller is in promiscuous mode, then this field will return the universal 
address slot, whether or not any address matched. If the controller is not in 
perfect filtering mode, then this field will return the universal address slot when 
any multicast packet is received. 

6.4.6. Number of Buffer Blocks Field 

The number of buffer blocks field specifies the number of buffer length/buffer 
address field pairs that follow this field in the request message. Each pair 
describes one block, where a buffer may consist of up to eight disjoint blocks in 
shared memory. This field's value is preserved in the reply message. 

6.4.7. Buffer Block Length Field 

The buffer block length field specifies the length in bytes of the buffer block 
whose address follows. The sum of all buffer block length fields should be the 
total packet length. The length does not include the preamble but must include 
4 bytes for the frame check sequence (CRC) field. In order to receive the 
longest possible Ethernet packet, the buffer must be at least 1518 bytes long. 
Minimum size is 64 bytes, which will fit the shortest possible Ethernet packet. 

In the reply message, the buffer length field total returns the number of bytes 
actually received, plus 4 bytes for the CRC field. Note that the CRC value is not 
actually written back. Also, if the buffer supplied was smaller than the packet 
received, then the excess bytes are truncated, and the buffer length will not give 
the true length of the packet. 

6.4.8. Data Address Field 

The data address field specifies the address of a buffer block in shared memory, 
where up to eight blocks compose a buffer. Note that the packet returned by 
NX 200 does not include a preamble, so that the address of the first block will 
point to the first byte of the packet's destination field. The data address field is 
preserved in the reply message. 
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6.5. NET.MODE REQUEST/REPLY MESSAGE 

The NET_MODE request is used to read/write the network controller mode and 
options mask objects. For details of these, refer to Sections 8.3 and 8.4. 
Figure 6-5 shows the format of the NET_MODE request/reply message, and the 
following paragraphs describe its individual fields in detail. 
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Figure 6-5: NET_MODE Request/Reply Message 



6.5.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 

6.5.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

6.5.3. Request Code Field 

The request code field defines the request. Its value in the NET_MODE request 
message must be 08H. This value is preserved in the reply message. 
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6.5.4. Return Code Field 

The return code field is undefined in the request message. In the reply 
message, it reports the status of the NET_MODE request: 

Successful completion. 

0A1 H Failed, NX 200 is not in controller mode. 

6.5.5. Request Mask Field 

The request mask field is defined as follows: 

01 Write request bit. 

02 Read request bit. 

Read and write can be requested simultaneously (mask = 03). Other bits in the 
mask must be 0, or effects are undefined. 

The request mask's value in the reply message is undefined. 

6.5.6. Options Mask Field 

The options mask field defines several available controller options. Available 
options are defined by the following bit OR-able values: 

10H Alignment error - enables reception of packets even if the 
number of bits received is not a multiple of 8. 

20H CRC error - enables reception of packets even if the CRC 
check fails. 

80H Net disable - disables the Ethernet controller so that packets 
are not received or transmitted on the Ethernet. However, 
transmit requests are still processed by NX 200, and to user 
processes appear to complete successfully if an on net mode is 
selected. 

All other bits are undefined and must be 0. This parameter is required only if a 
write is requested. If the read bit in the request mask of the request message 
was set, then this field returns the options mask prior to the request. Otherwise 
its value in the reply message is undefined. 

6.5.7. Mode Field 

The mode field specifies the new mode of the Ethernet controller. Possible 
values are: 

00H Disconnect from the net. 

01 H Connect to net, perfect filter for multicast addresses. 

02H Connect to net, only hardware filter for multicast addresses. 

03H Connect to net, receive all packets (promiscuous mode). 

This parameter is required only if a write is requested. If the read bit in the 
request mask of the request message was set, then this field returns the net 
mode prior to the request. Otherwise its value in the reply message 
is undefined. 
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6.6. NET_ADDRS REQUEST/REPLY MESSAGE 

The NET_ADDRS request is used to read/write an address in a specified 
address slot. For information about address slots, see Section 6.6. 

If a network address to be written is invalid, the write does not occur, and the 
address in the slot prior to the request is preserved. Writing an address into a 
slot disables reception on that slot. The NET_RCV request must be explicitly 
used to re-enable reception on the slot. 
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Figure 6-6: NET AODRS Request/Reply Message 



Figure 6-6 shows the format of the NET_ADDRS request/reply message, and 
the following paragraphs describe its individual fields in detail. 

6.6.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 
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6.6.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

6.6.3. Request Code Field 

The request code field defines the request. Its value in the NET_ADDRS 
request message must be 09H. This value is preserved in the reply message. 

6.6.4. Return Code Field 

The return code field is undefined in the request message. In the reply 
message, it reports the status of the NET.ADDRS request: 

Successful completion. 

0D1 H The specified slot does not exist or access is not permitted. 

0D3H Improper address. Multicast slots can only take multicast 
addresses and the physical slot can only take a physical 
address. Attempting to write the broadcast slot (number 255) 
results in this error. 

0A1 H Failed, NX 200 is not in controller mode. 

6.6.5. Request Mask Field 

The request mask field is defined in the request message as follows: 

01 Write request bit. 

02 Read request bit. 

Read and write can be requested simultaneously (mask = 03). Other bits in the 
mask must be 0, or effects are undefined. 

In the reply message, if bit 3 (mask value 8) is set, then the address slot contained a 
valid address prior to this request. Otherwise the slot was empty. All other bits are 
undefined. This result is defined only if a read was requested. 

6.6.6. Address Slot Field 

The address slot field designates the address slot which is to be accessed. This 
can be the physical address slot (253) or any multicast address slot (between 1 
and the limit defined by configuration). 

This field's value is preserved in the reply message. 

6.6.7. Net Address Field 

The net address field, if a write is requested, should contain a valid network 
address to be written in the specified slot. In the reply message, if a read was 
requested, and the slot was not empty, then this field returns the net address in 
the specified slot prior to this request. Otherwise it is undefined. 
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6.7. NET_RECV REQUEST/REPLY MESSAGE 

This request is used to read/alter the receive status of an address slot (see 
Section 6.6). 

Figure 6-7 shows the format of the NET_RECV request/reply message, and the 
following paragraphs describe its individual fields in detail. 



# Length Offset Field Name 



Request Reply 



1) 2 



2) 4 



3) 


1 


6 


4) 


1 


7 


5) 


1 


8 


6) 


1 


9 



Reserved for NX Usage 



User Id Code 



Request Code 
Return Code 



Request Mask 
Address Slot 



(--,AL) 
( DL , DL ) 
( DH , - - ) 



zero 



unde f i ned 



undefined preserved 



OAH preserved 

unde f i ned see t ex t 

see text see t ex t 

see text preser ved 



1 byte >| 



Figure 6-7: NET.RECV Request/Reply Message 



6..7.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 

6.7.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

6.7.3. Request Code Field 

The request code field defines the request. Its value in the NET_RECV request 
message must be OAH. This value is preserved in the reply message. 

6.7.4. Return Code Field 

The return code field is undefined in the request message. In the reply 
message, it reports the status of the NET_RECV request: 
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Successful completion. 

0D1 H The specified slot does not exist or access is not permitted. 

0D2H The specified slot was empty. 

0A1 H Failed, NX 200 is not in controller mode. 

6.7.5. Request Mask Field 

The request mask field is defined in the request message as follows: 

01 Write request bit. 

02 Read request bit. 

04 Enable receive bit. 

Read and write can be requested simultaneously (mask = 03). Other 
bits in the mask must be 0, or effects are undefined. 

If the write bit in the request mask is set, then reception on the designated 
address slot will be enabled or disabled, depending on the value of the enable 
receive bit. 

In the reply message, if bit 2 (mask value 4) is set, then receive was enabled for 
this slot prior to this request. Otherwise it was disabled. All other bits are 
undefined. This result is defined only if a read was requested. 

6.7.6. Address Slot Field 

The address slot field designates the address slot which this request will work 
on. This can be the physical address slot (253), the broadcast slot (255), or any 
multicast address slot (between 1 and the limit defined by configuration). 

This field's value is preserved in the reply message. 

6.8. NET.STSTCS REQUEST/REPLY MESSAGE 

This request reads/resets the statistics objects (see Section 6.7). If the read bit 
is set in the request mask, then a specified number of statistics objects, starting 
at the objects index field, are copied into the array specified by the buffer 
address field. Note that the statistics copied into host memory are defined only 
after the reply message has been received. 

If the write bit is set in the request mask, then the number of objects specified 
by the number of objects field, starting with the object specified by the objects 
index, are reset to zero. If the objects index field is out of range, then no 
objects are read/reset. 

Figure 6-8 shows the format of the NET_STSTCS request/reply message, and 
the following paragraphs describe its individual fields in detail. 

6.8.1. Reserved Field 

The first field is reserved for use by NX 200, and must be set to 0. Its value in 
the reply message is undefined. 
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# Length Offset Field Name 



Request Reply 
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see text see text 
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9) 4 



1 4 



Buffer Address ("ES+DI,--) I see text preserved 



I --. 1 byte- 

Figure 6-8: NET_STSTCS Request/Reply Message 



6.8.2. User Id Code Field 

The user id code field is not interpreted by NX 200, and is returned unmodified 
in the reply message. It can be used to establish a correspondence between 
request and reply messages. 

6.8.3. Request Code Field 

The request code field defines the request. Its value in the NET_STSTCS 
request message must be OBH. This value is preserved in the reply message. 

6.8.4. Return Code Field 

The return code field is undefined in the request message. In the reply 
message, it reports the status of the NET_STSTCS request: 
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Successful completion. 

0A1 H Failed, NX 200 is not in controller mode. 

6.8.5. Request Mask Field 

The request mask field is defined in the request message as follows: 

01 Write request bit. 

02 Read request bit. 

Read and write can be requested simultaneously (mask = 03). Other 
bits in the mask must be 0, or effects are undefined. 

The read request copies the specified portion of the statistics array into the 
specified buffer. The write request resets the specified portion of the statistics 
array. If both read and write are requested, the read is done first. This field is 
undefined in the reply message. 

6.8.6. Reserved Field 

This field must be zero in the request message. Its value in the reply message 
is undefined. 

6.8.7. Number of Objects Field 

The number of objects field specifies how many statistics objects are to be 
read/reset. In the reply message, this field returns the number of objects that 
were actually read/reset. If the number requested exceeds the bounds of the 
statistics array, it will be truncated. 

6.8.8. Objects Index Field 

The objects index field specifies the starting place in the statistics array at which 
objects will be read/reset. Its value is preserved in the reply message. 

6.8.9. Buffer Address Field 

The buffer address field specifies the address of the buffer in shared memory to 
which the requested portion of the statistics object array will be copied, if a read 
request was made. This field is defined only if a read is requested. Its value is 
preserved in the reply message. 
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Chapter 7 
PROGRAMMING ENVIRONMENT 



7.1. INTRODUCTION 



This section provides the information necessary to write higher-level software to 
execute under the NX 200 kernel on an EXOS Intelligent Ethernet Controller. 
The first few sections describe environmental considerations, such as memory 
allocation, which commonly affect software design. Subsequent sections 
explain the abstract objects and operations implemented in NX 200. 

All programs for the intelligent Ethernet controller execute under NX 200, an 
EPROM-resident multitasking operating system kernel. Programs can be written 
in any language for the CPU and can be located anywhere in the memory 
available to the user. They can be downloaded either from the host or over the 
network. Refer to the section " Downloading Software from the Host", in the 
appropriate "Initialization and Host Interface" chapter, for details. 

NX 200's multitasking environment facilitates the structured implementation of 
high-level protocol software, as a set of cooperating processes. Facilities 
include mechanisms for process synchronization, interprocess communication, 
scheduling, and clock-based functions. None of the hardware devices on the 
board, viz., the clock, the Host interface or the Ethernet controller, require direct 
access by user processes. Instead, NX 200 has built-in drivers which provide 
suitable abstractions of the devices, so that programs developed for the EXOS 
Intelligent Ethernet Controller are independent of actual hardware 
implementation. 

All functions of NX 200 are accessed by means of NX calls executed by an 
INT "n" instruction, where n defines the desired function. Parameters to the 
calls are generally passed in CPU registers. However, it is easy to write 
interface libraries to permit NX calls to be made from programs written in high 
level languages such as C, PASCAL, etc. 

7.2. MEMORY ORGANIZATION 

The board CPU provides an address space of 1 Mbyte, accessible in 64K 
segments, on 16-byte bounds. Figure 7-1 shows how this address space is 
allocated on the EXOS Intelligent Ethernet Controller, under the default 
configuration of NX 200. The default configuration provides a given number of 
objects, such as mailboxes and process table entries. This allocation, specified 
in the Memory Map Size Field section in the appropriate chapter of Initialization 
and Host Interface, should be sufficient for most applications. However, the 
allocation of objects under NX 200 can be changed at initialization time, with a 
corresponding effect on RAM allocation. The following paragraphs explain the 
use of NX 200 memory in detail. 

7.2.1. Interrupt Vector Table 

In the default configuration, NX 200 allocates 512 bytes for the interrupt vector 
table, providing 1 28 entries of 4 bytes each. Of these, 32 interrupt vectors are 
available for user definition. If more are required, the interrupt vector table may 
be reconfigured to its full size of 1024 bytes. Interrupt allocation is explained 
below in more detail. 
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Address 

FFFFFH 



Func t i on 



Reserved Address Space 



Si ze 



COOOOH (768 Kbyte) 



3FFFFH 



1 FFFFH 



OOFFFH 



003 FFH 
001 FFH 
00000 



Optional Dual-ported RAM 

(Model 3) or 

Re served (Mo del 2 ) 

Dua I -Por ted User RAM 



20000H (128 Kbytes) 



1F000H (124 Kbyte) 



Fixed NX 200 Data Area 



00C00H (3 Kbyte) 



Movable NX 200 Data Area 
Interrupt Vector Table 



00200H (1 12 Kbyte) 
00200H ( 1 /2 Kbyte) 



l< 1 byte >| 

Figure 7-1 : Default EXOS Intelligent Ethernet Controller Memory Allocation 



7.2.2. Movable NX 200 Data Area 

The movable NX 200 data area is the memory required for data structures which 
NX 200 associates with objects. User software should not access this memory 
area directly. 

The length of the movable data area depends on the maximum number of 
objects supported, which is configured during NX 200 initialization (refer to the 
Initialization and Host Interface section for the appropriate bus system). It can 
be computed by the expression 16*(P + M) + 8*A bytes, where P is the number of 
processes, M is the number of the mailboxes and A is the number of address 
slots. In the default configuration this area is 512 bytes long, occupying 
locations 200H through 3FFH. 

If the NX 200 reconfiguration requires more than 512 bytes in this area, or if 
locations 200H to 3FFH are needed for an expanded interrupt vector table, then 
this area can be moved to any memory area between 1000H and 0FFFFH. 
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7.2.3. Fixed NX 200 Data Area 

NX 200 uses this memory area for data structures that are not dependent on its 
configuration. It is always 3 Kbytes long and occupies locations 400H through 
0FFFH. It cannot be moved. User software should not directly access the fixed 
data area. 

7.2.4. Dual-Ported User RAM 

128 Kbytes of RAM on the EXOS Intelligent Ethernet Controller, from location 
to 1FFFFH, is dual-ported between the board CPU and the Ethernet controller 
hardware. Of this, 124 Kbytes between 1000H and 1FFFFH, are entirely 
available in the default configuration for the purposes of downloaded user 
software. If the movable data area must be moved from its default location, 
then some small portion of this RAM will become unavailable for user software. 
NX 200 requires that all message buffers (used for communicating data between 
processes, host, and network) lie in dual-ported user RAM. 

7.2.5. Optional Dual-Port RAM 

On the EXOS Intelligent Ethernet Controller Model 3 only, additional 128 Kbytes 
of RAM, from location 20000H to 3FFFFH is also available for the purposes of 
downloaded software. 

7.2.6. Reserved Address Space 

The address range 20000H-FFFFFH on the Model 2, or 40000H-FFFFFH on the 
Model 3, is reserved. The effects of access to this area by user software are 
not defined. 

Other than those described above, NX 200 imposes no restrictions on how 
memory is used. Users can link and load their programs in any manner they 
please. NX 200 does not define any buffer management services; users may 
choose the optimum scheme for individual applications. 

7.3. INTERRUPT TYPES 

The board CPU provides 256 interrupt types, each of which corresponds to a 4- 
byte interrupt vector table entry. NX 200 allocates these as follows: 

0-31 Reserved/dedicated by Intel 

32-63 Device interrupts (used by NX 200) 

64-95 NX 200 calls 

96-127 Available to user software by default 

128-255 Available to user software by reconfiguration 

User software should not modify interrupt vectors for types 0-95. In the default 
configuration, types 96-127 are available for user definition. If more interrupt 
types are required, then the movable data area can be relocated (refer to 
Section 7.2.2), making types 128-255 available. 

NX 200 provides all interrupt service routines necessary for EXOS Intelligent 
Ethernet Controller hardware and the host interface. Therefore it is unlikely that 
user applications would require hardware interrupt service routines. However, it 
may be convenient to use the user-definable interrupt types as an interface 
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between user software modules. If this is done, then the software interrupt 
service routines should be sure to re-enable interrupts immediately upon entry. 

7.4. PROCESSES 

NX 200 supports processes as they are usually understood: a program in 
execution. Processes can be freely created and deleted. At any one time the 
number of processes cannot exceed a maximum number defined by the 
configuration of NX 200 (refer to Section 7.2.2; NX 200 Movable Block Address 
Field). 

7.4.1. Process Address Space 

NX 200 does not impose memory protection between processes. All processes 
share the same 1 -Mbyte address space, allowing them to communicate via 
shared memory. However, the context of each process includes the segment 
register file of the CPU. Thus each process can independently choose its own 
direct address space. The CPU memory addressing architecture permits 
shared-text processes and dynamic relocation of code modules. 

7.4.2. Process-id 

Each process is identified by a unique one-word integer called its process-id. 
This number is used to refer to processes in all NX 200 calls. The process-id of 
a process which has been deleted is not re-used until at least 255 additional 
processes have been created after the deletion. Applications which create and 
delete processes very frequently should beware of this fact. The process-id is 
a special id and always refers to the process currently executing. Thus a 
process can refer to itself by using instead of its actual id in an NX 200 call. 
When a process is first created its id is available in one of its CPU registers, as 
specified in the PROC_CREATE call description. A process can also find its 
own id by executing a read-only call (such as PROC_PRIOR), specifying as 
the process-id parameter. NX 200 calls return the actual process-id even if 
was used as an input parameter. 

7.4.3. Process Stack 

The stack address of a new process is supplied as a parameter to the 
PROC_CREATE call, by the process invoking this call. NX 200 creates the first 
process, and allocates its stack within the fixed NX 200 data area (see section 
7.3.3) Stack areas can be allocated anywhere in memory. When deciding stack 
size, the user should be aware that NX 200 does not maintain any separate 
system stack for a process. When NX 200 services interrupts, it uses the stack 
of the process executing when the interrupt occurs. In order to prevent stack 
overflows it is recommended that the user process stack have at least 64 bytes 
of the stack is available for NX 200 interrupt service routines. 

7.4.4. Process Scheduling 

Four parameters visible to user software drive NX 200's process scheduling 
algorithm: 

• Priority 

• Time slice 
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• Time count 

• Sleep count 

All but time count are explicitly set when a process is created, and can be examined or 
modified by any process subsequently. Time count can be examined, but its value is 
implicitly determined by time slice. 

Priority is a number between and 255 where is the lowest priority. NX 200 
maintains a logically separate scheduling! queue of processes for each priority level. 
Process priority remains constant, unless rhodified by an explicit call to PROC_PRIOR. 

Time slice is a number between and 2$5 which determines the amount of CPU time 
that a process can use before its position in the scheduling queue is re-evaluated. 
Implementation is as follows. 

Time count is initialized with the value of | time slice, and counts down at the rate of 20 
milliseconds, but only while the process isjactually executing. When time count reaches 
0, the process is put at the end of its scheduling queue, and time count is reinitialized 
with time slice. A process's time slice regains constant, unless modified by an explicit 
call to PROCJTIMSLC. A value of -1 for time slice is considered infinity. 

Sleep count is a number between and 64K-1 that represents the amount of real time 
which must elapse before the process becomes eligible to use the CPU. A process 
having a non-zero sleep count is said to be sleeping and a process with a sleep count of 
zero is said to be executable. Sleep count also counts down at a rate of 20 
milliseconds, and a value of -1 is considered infinity. By definition, however, the sleep 
count counts down only while the process is not executing. When sleep count reaches 
zero, it remains zero and the process becomes executable. 

The scheduling parameters are used to implement a pre-emptive round robin scheduling 
algorithm as follows. Whenever scheduling occurs, the CPU is given to the first 
executable process in the highest priority scheduling queue. Scheduling occurs on 
every tick of the NX 200 clock (20 milliseconds), and whenever some scheduling 
parameter changes. For instance, if during the execution of a process some other 
process with a higher priority becomes executable, then the CPU is immediately given to 
the higher priority process without changing the position or time slice count of the pre- 
empted process. Similarly, if the sleep count of a executing or a executable process is 
set to a non-zero value either by an explicit NX 200 call or by an implicit side effect of 
some other NX 200 call, then the process is put to sleep without changing its time slice 
count or position in its priority queue. 

It should be noted from the above discussion that a executable process cannot have a 
non-zero sleep count. Thus setting the sleep count of a process to zero makes it 
executable, and setting it non-zero suspends the process. The PROC_SLPCNT call can 
be used by any process to alter the sleep count of any process. The new value 
overwrites the previous value of the sleep count, which is forgotten. By choosing an 
appropriate value for sleep count, a process can be delayed, suspended or resumed. 
As such, no separate calls for these capabilities are included in NX 200. 

It should also be noted that if an infinite time slice is given to all processes then the 
scheduling policy reduces to a priority-based event driven scheduling algorithm. 
Running all processes at equal priority besides reduces the policy even further, to strictly 
event-driven scheduling. 



7-5 



NX 200: Programming Environment 

"/.4.5. Implicit Scheduling Factors 

When a user process makes an NX 200 kernel call, it is locked until the call 
completes. Therefore the process will not be pre-empted by another user 
process unless the kernel call itself blocks the calling process. For instance, a 
MLBX_RECV call might cause re-scheduling before it completes, if no message 
is queued on the indicated mailbox. On the other hand, a MEM_READ or 
MEM_WRITE will always exclude other user processes until the call is 
completed. 

NX 200 interrupt service routines will always interrupt any user process, and will 
interrupt each other according to the following priority scheme: 

0. Clock Tick 

1 . Ethernet Transmit Completion 

2. Ethernet Receive Completion 

3. Host Interface Event 

where is the highest priority. Note that any of these events can cause re- 
scheduling of user processes. For instance, an Ethernet Receive completion 
might place an Ethernet receive reply message on a reply mailbox, and 
therefore reset the sleep count of a process enqueued there. 

7.5. MAILBOXES 

Interprocess communication and synchronization is supported primarily by 
mailboxes. A mailbox, like a process, is an object that can be created and 
deleted. The maximum number of mailboxes that can exist is defined by the 
configuration of NX 200 (see the section titled; Number of Mailboxes Field, in 
the appropriate "Initialization and Host Interface" chapter). 

7.5.1. Mailbox-id 

Each mailbox is identified by a unique one word integer called its mailbox-id. 
This number is used to refer to mailboxes in all NX 200 calls. When a mailbox 
is deleted its id is not re-used until at least 255 mailboxes have been created. 
Applications which create and delete mailboxes very frequently should beware of 
this fact. 

7.5.2. Messages 

A mailbox provides the facility to transfer messages between processes. A 
message is a memory-resident data structure with an arbitrary format, except for 
a mandatory 32-bit link field at its beginning. NX 200 uses the link field to chain 
messages. They must reside within the address range 0-0FFFFH in EXOS 
Intelligent Ethernet Controller memory. 

Since all processes share the same address space, messages are not copied by 
mailbox operations. Instead, pointers to messages are sent and received 
through the mailbox. It is the responsibility of the sending process to maintain 
the message data intact until the receiving process no longer requires it. The 
user must devise some scheme to ensure coordinated use of message data 
structures. 
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7.5.3. Null Messages 



The null message is a special case which is identified by a null pointer and does 
not have any data associated with it. They are used strictly for process 
synchronization purposes, and can share a mailbox with regular messages. 
Note that null messages cannot be differentiated from one another. 

7.5.4. Sending and Receiving Messages 

The sending and receiving of messages through a mailbox is fully synchronized. 
Each mailbox has a message queue and a process queue. When a mailbox is 
created (using the MLBX_CREATE call) the process queue is empty and the 
message queue contains a specified number of null messages. 

A message is sent to a mailbox by the MLBX_SEND call. When a regular 
message is sent it is appended after all other regular messages in the message 
queue but in front of all the null messages, if any. A null message is always 
appended after all the regular messages in the queue. Thus regular messages 
are delivered on a first-in first-out basis while null messages are delivered if and 
only if there are no regular messages in the queue. 

A message is received from the mailbox by the MLBX_RECV call. A process 
receives the first message from the message queue if it is not empty. 
Otherwise, the process is appended to the end of the process queue and its 
sleep count is set to the value specified as a parameter to the MLBX_RECV call. 
Recall that if the sleep count of a process is nonzero the process is blocked until 
it counts down to zero. A subsequent MLBX_SEND call removes the first 
waiting process from the process queue, hands it the message and unblocks it 
by setting its sleep count to zero. When the unblocked process resumes 
execution, the MLBX_RECV call which blocked the process returns with a 
completion code indicating success. 

If the sleep count of a blocked process counts down to zero or is explicitly set to 
zero by a PROC_SLPCNT call then the process is forced to unblock even if no 
message has arrived. In this case the unblocked process returns from the 
MLBX_RECV call with a nonzero completion code indicating the time 
out condition. 

It should be noted from the above discussion that a process blocks on a mailbox 
only when the sleep count of the process is non-zero. Thus if a process 
executes a MLBX_RECV call with the sleep count parameter equal to zero, then 
the process will not block even if no messages are available. By choosing an 
appropriate value of the sleep count parameter, a process can test the 
availability of a message without blocking, block unconditionally until a message 
arrives, or block for a finite specified amount of time waiting for the message 
to arrive. 

7.5.5. Mailboxes as Semaphores 

The notion of null messages allows the mailbox to be used as a conventional 
semaphore. If only null messages are used then the MLBX_SEND call is 
equivalent to the V operation and the MLBX_RECV call is equivalent to the P 
operation. Thus a mailbox can be used both for synchronizing a producer- 
consumer relationship or for mutual exclusion. 
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7.6. PROCESS LOCKS 

Using the mailbox for mutual exclusion may be a little more expensive than 
desired for simple cases such as updating a single variable. NX 200 provides 
the process lock as a simpler, alternate mechanism for mutual exclusion. A 
lock, when in effect, causes scheduling to be suspended. The call 
PROC_LOCK puts a lock in effect and the call PROCJJNLOCK removes a lock. 
Lock calls can be nested up to 32K deep; before a process is unlocked, unlock 
calls must balance lock calls. If a process with locks in effect makes an NX 200 
call which can potentially cause the process to sleep then all locks are removed 
regardless of whether the process actually went to sleep or not. 

The process executing a lock call excludes all other process from executing and 
thus imposes a stronger condition than the mailbox mechanism, which excludes 
only the processes that intend to use the critical section. On the other hand, the 
lock call executes faster than the mailbox calls, and a lock does not consume 
memory resource as does a mailbox object. The lock call cannot be used for a 
producer-consumer type of synchronization. For mutual exclusion the users can 
select the mechanism which best suits the application. 

Both mailboxes and locks provide mutual exclusion between processes; 
however, interrupts are not excluded. As such the only way to share a critical 
section between a process and an interrupt service routine is to disable 
interrupts for the duration of the critical section. Programmers usually need not 
be concerned with this fact, since all necessary interrupt handlers are included 
in NX 200. In general the user programs should not disable interrupts. 

7.7. SYSTEM MAILBOXES 

Certain NX 200 services are asynchronous by nature, such as sending and 
receiving messages with Ethernet or the host. All such system services are 
provided in a conceptual sense by system processes. These are like user 
processes in that they execute asynchronously, but they have no process-id or 
visible scheduling parameters. User processes access system process services 
by sending a request message to a special "system mailbox" associated with the 
desired service. 

System mailboxes are created by NX 200 during initialization and are not 
included in the number of user mailboxes specified by the configuration of 
NX 200. The set of mailbox-ids for regular mailboxes is disjoint with the set of 
mailbox-ids for system mailboxes. NX 200 designates the following system 
mailbox-ids: 

0001 H Host 
0009H Ethernet 

Request messages are sent through the system mailbox using the MLBX_SEND 
call. The system service after completing the request, returns the reply 
message to the reply mailbox specified in the request message. After sending a 
request message, a process can continue to execute or wait until the reply 
message is returned. The request message, once sent, should not be modified 
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until the reply message is received. The user process can receive the reply 
message from the reply mailbox using the MLBX_RECV call. 

The formats of request messages and their corresponding reply messages are 
defined by each individual service. All messages, however, have a standard 
header. Figure 7-2 shows this header, and the following paragraphs explain 
each field in detail. 



Length Offset 



Field Name 



Request Reply 



1) 



2) 2 

3) 1 

4) 1 



L ink 



Re p I y Ma i I b o x 



Request Code 
Return Code 



Additional Fields Defined by 
Individual System Processes 



unde f i ned unde f i ned 



see t ex t see text 

see text see text 
see text see text 



| < 1 byte- 

Figure 7-2: Standard Header for System Messages 



7.7.1. Link Field 

The link field is required by NX 200 at the beginning of all messages. Its 
request and reply values are both undefined. NX 200 uses this field for chaining 
messages. 

7.7.2. Reply Mailbox Field 

The reply mailbox field specifies the mailbox to which the request message is 
returned after the completion of the requested service. System mailboxes 
cannot be used as reply mailboxes. 

7.7.3. Request Code Field 

The request code field specifies the service to be performed, typically read or 
write. 
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7.7 A. Return Code Field 

The return code field is the result of the request filled in by the system process. 
The actual values for the request and return codes are defined by individual 
system services. 

7.8. THE CLOCK DEVICE 

NX 200's abstraction of the clock device is a simple 64-bit counter, incremented 
in real time every 20 milliseconds. On reset the counter is set to zero. 
Processes can set the clock counter to any value at any time with the 
TIME_SET call, and read it at any time with the TIME_GET call. The clock 
counter can be used for any purpose required by the user application. For 
example, it may be used as a time-of-day clock by setting it to the current time. 

Note this model of the clock provides no facility to the user for interrupting after 
a specified interval of time. This clock-related function has been incorporated 
directly in NX 200's multitasking model by the sleep count parameter, which can 
be used to delay a process or force a blocked process to unblock after a 
specified interval of time. 
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Chapter 8 
ETHERNET INTERFACE 



8.1. INTRODUCTION 



The NX 200 interface to Ethernet consists of two parts: a system process which 
sends and receives packets, and a set of several NX 200 kernel calls which 
serve network management functions. This section describes all necessary 
details of the Ethernet system process, and describes the functionality of the 
network management calls. For further details about NX 200 call format, refer 
to Section 10. 

User processes send Ethernet transmit and receive requests to the Ethernet 
system process via the Ethernet system mailbox (0009H). The transmit request 
describes the location of a packet to transmit, while the receive request 
describes a buffer in which to store an incoming packet. In both cases, the 
request names a reply mailbox, to which the system process sends a reply 
message when the request completes. Requests may be enqueued without 
limit, and will be processed asynchronously. Transmit requests are serviced as 
rapidly as the Data Link protocol permits, and return a failure only in the event of 
excess collisions. Receive requests return a reply message only when an 
incoming packet satisfies all specified address filtering. 

Network management functions determine the Ethernet controller's mode, define 
which addresses to accept, and gather network statistics. All of these are 
defined in terms of abstract objects, accessed only via the appropriate NX 200 
calls. In each call, a request mask parameter determines whether the request 
will read or write (or read and write) a value to/from a given object. This 
approach simplifies access to network management functions, and insulates the 
functions from specific implementation methods. 

8.2. ETHERNET TRANSMIT REQUEST 

To send a packet on the Ethernet, a process sends a service request message 
to the Ethernet system mailbox. When transmission is complete, the request 
message (modified according to the status of the transmission) is returned to a 
reply mailbox designated by the requesting process. The request message 
does not contain the actual data to be sent, but rather a pointer to the packet. 
Any number of messages can be sent to the Ethernet system process; they will 
be queued up and dispatched in the order received. Until the reply message is 
received, the message and packet belong to the Ethernet process, and should 
not be modified. 

Transmit requests are serviced immediately, unless the controller is in off net 
mode (refer to Section 6.5). When a NET_MODE call places the controller off 
net, any transmission underway will complete, but any enqueued requests will 
remain enqueued. When off net, new transmit requests may still be enqueued. 
When the controller is restored to an on net mode, transmission resumes. 

If the net disable option is selected, (refer to Section 6.6) then transmission will 
appear to proceed normally, but nothing is actually transmitted on the Ethernet. 

Packets are prepared for transmission in standard Ethernet data link layer frame 
format, as shown in Figure 8-1. However, the packet need not include a frame 
check sequence (CRC) field. This, and the preamble, are generated by the 
EXOS Intelligent Ethernet Controller. 
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(generated by EXOS H/W) 



1 byte 



Figure 8-1 : Ethernet Packet Format 



Figure 8-2 shows the format of an Ethernet transmit request/reply message. Its 
fields are explained in detail below. 

8.2.1. Link Field 

The link field is required by NX 200 at the beginning of all messages. Its 
request and reply values are both undefined. NX 200 uses this field for 
chaining messages. 

8.2.2. Reply Mailbox Field 

The reply mailbox field identifies the mailbox to which the reply message is 
returned after completion of the request. In the request message, this must 
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identify an existing user mailbox. Its value in the reply message is the Ethernet 
system mailbox id. 

8.2.3. Request Code Field 

The request code field defines the request; in this case, to send a packet, its 
value in the request message must be 0. The reply message preserves this 
value. 

8.2.4. Return Code Field 

The return code field value in undefined in the request message. In the reply 
message, it reports the status of the transmission request: 

00H Successful transmission, no retry. 

01 H Successful transmission, 1 retry. 

02H Successful transmission, more than 1 retry. 
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08H (Applicable for Version 2.0 transceivers only.) Indicates the 
absence of SQE (heartbeat) TEST signal during the Inerframe 
Spacing interval. This error code is OR-able with all other 
message values except 40H and 0A1H. A jumper option is 
available to disable this check. 

10H Transmission failed, excessive collisions. 

20H No Carrier Sense signal detected during transmission. 

40H Transmission failed, transmit length not in range. 

CBH Transmit request not completed within the 6-second time limit, 
possibly due to a faulty transceiver or a faulty transceiver cable. 

8.2.5. Address Slot Field 

The address slot field is an index into the address slot array (refer to Section 
6.6.6). Its value in the request message is undefined. In the reply message, it 
contains the address slot number by which this packet would be received by this 
station. For instance, the value 255 indicates that the packet was broadcasted, 
and should be auto-received. Or, if the packet was transmitted to this station's 
own address, the value would be 253. A zero value means that no slot matched 
- this packet would not be received by this station. 

8.2.6. Reserved Field 

This field is reserved for future use. In the request message, its value must be 
0. In the reply message, its value is undefined. 

8.2.7. Data Length Field 

The data length field is the length, in bytes, of the packet to be transmitted. This 
value does not include the preamble or CRC fields, which are appended by the 
EXOS 200 Series board. In the reply message, the data length field's value is 
undefined. 

8.2.8. Data Address Field 

The data address field is the address of the packet to be transmitted. This is a 
segmented address (refer to Section 1.14); the first word is an offset, the 
second word a segment base address. NX 200 requires that the packet start at 
an even boundary and lie entirely within the address range 1000H-0FFFFH. 
Additionally, the segment base address must be 0. Note that the packet, as 
handed over to the Ethernet process, does not include a preamble, so that the 
address will point to the first byte of the packet's destination field. The data 
address field's value is preserved in the reply message. 

8.3. ETHERNET RECEIVE REQUEST 

In order to receive a packet on the Ethernet, a process sends a service request 
message to the Ethernet System mailbox. The request message does not 
contain the actual buffer to be filled, but rather a pointer to the buffer. When 
reception is complete, the request message (modified according to the status of 
the reception) is returned to a reply mailbox designated by the requesting 
process. Once the reply message is received, the buffer belongs to the 
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receiving process. Receive requests are not necessarily dispatched in the order 
they are received by the Ethernet system process. 

The EXOS 200 Series board manages receive buffer descriptors in hardware; it 
can receive packets back-to-back with minimum interframe spacing as long as 
sufficient receive requests have been enqueued. For most applications, it is 
recommended that at least two receive buffers be made available at all times. 
This allows time for the EXOS CPU to screen out undesired packets (such as 
spurious network bootstrap protocol messages, or multicast packets which 
passed the hardware filter) which would otherwise tie up a single-buffered 
implementation. By queuing up a fairly large number of receive buffers, 
protocols can create a large "receive window" and realize substantial 
performance improvements. 

Receive requests return a reply message to a designated reply mailbox only 
after an incoming packet satisfies the receive address filtering criteria. When a 
NET_MODE call (refer to Section 10) places the controller off net, any receive 
underway will complete, but any enqueued requests will remain enqueued. 
Packets arriving on the Ethernet will be ignored (not placed into receive buffers). 
When off net, new receive requests may still be enqueued. 

If the net disable option is selected, (refer to Section 6.5) incoming traffic is 
ignored, and receive requests will not return a reply message until the controller 
is re-enabled. 

If the EXOS 200 Series board was initialized in network bootstrap mode, once 
the network bootstrap session is completed, it will not pass messages of the 
network bootstrap type to software running under NX 200. This prevents any 
spurious network bootstrap messages from interfering with successfully-installed 
protocol software on the EXOS 200 Series board. 

Received packets are in standard Ethernet data link layer frame format, as 
shown in Figure 8-1. The frame check sequence (CRC) field is included. 

Figure 8-3 shows the format of an Ethernet receive request/reply message, 
which is very much like the transmit request/reply message. Its fields are 
explained in detail below. 

8.3.1. Link Field 

The link field is required by NX 200 at the beginning of all messages. Its 
request and reply values are both undefined. NX 200 uses this field for chaining 
messages. 

8.3.2. Reply Mailbox Field 

The reply mailbox field identifies the mailbox to which the request message is 
returned after completion of the request. In the request message, this must 
identify an existing user mailbox. Its value in the reply message is the Ethernet 
system mailbox id. 

8.3.3. Request Code Field 

The request code field defines the request; in this case, to receive a packet, its 
value in the request message must be 1. The reply message preserves this 
value. 
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8.3.4. Return Code Field 

The return code field value in undefined in the request message. In the reply 
message, it reports the status of the receive request: 

00H Packet received with no error. 

04H Packet received longer than buffer supplied, truncated. 

10H Packet received with alignment error. 

20H Packet received with CRC error. 

40H No packet received, buffer supplied was less than 64 bytes. 

Note that packets with errors are actually received only if the network mode is 
set appropriately. 
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8.3.5. Address Slot Field 



The address slot field is an index into the address slot array (refer to Section 
6.6.6). Its value in the request message is undefined. In the reply message, 
this field contains the address slot number which matched the destination 
address of the packet received. If the controller is in promiscuous mode, then 
this field will return the universal address slot, whether or not any address 
matched. If the controller is not in perfect filtering mode, then this field will 
return the universal address slot when any multicast packet is received. 

8.3.6. Reserved Field 

This field is reserved for future use. In the request message, its value must be 
0. In the reply message, its value is undefined. 

8.3.7. Buffer Length Field 

The buffer length field is the length, in bytes, of the receive buffer. The length 
does not include the preamble but must include 4 bytes for the frame check 
sequence (CRC) field. In order to receive the longest possible Ethernet packet, 
the buffer must be at least 1518 bytes long. Minimum size is 64 bytes, which 
will fit the shortest possible Ethernet packet. 

In the reply message, the buffer length field returns the number of bytes actually 
received, including 4 bytes for the CRC field. Note that if the buffer supplied 
was smaller than the packet received, then the excess bytes are truncated, and 
the buffer length will not give the true length of the packet. 

8.3.8. Buffer Address Field 

The data address field is the buffer to receive a packet. This is a segmented 
address (refer to Section 1.14); the first word is an offset, the second word a 
segment base address. The EXOS 200 Series board requires that the buffer 
start at an even boundary and lie entirely within the address range 1000H- 
1FFFFH. Additionally, the segment base address must be 0. Note that the 
packet returned by the Ethernet process does not include a preamble field, so 
that the address will point to the first byte of the buffer's destination field. The 
buffer address field's value is preserved in the reply message. 

8.4. ETHERNET CONTROLLER MODES 

The Ethernet controller provides several optional modes of operation which 
essentially define filtering criteria for packets to be received. Processes can 
read and modify the controller's mode with the NET_MODE call, which selects 
one of four mutually exclusive modes: 

Off net - the EXOS 200 Series board is disconnected from the 
net. No transmission or reception of packets takes place. Note, 
however, that any transmission or reception in progress is 
completed before the network is actually disconnected. 
Transmit and receive requests can still be enqueued, and 
network management functions will be serviced. 

1 On net, perfect filtering - the EXOS 200 Series board is 
connected to the Ethernet. Multicast packets are received if 
and only if their destination addresses match one of the 
specified multicast addresses. A two level filter is employed - 
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the first level in hardware, which rejects a large fraction of the 
unwanted messages, and the second level in software, which 
traps the balance. 

2 On net, imperfect filtering - the EXOS 200 Series board is 
connected to the Ethernet. Only the hardware filter is used to 
select the desired multicast packets. It is possible to receive 
spurious multicast packets, which fall through the hardware 
filter. 

3 On net, promiscuous mode - the EXOS 200 Series board is 
connected to the Ethernet. All packets are received regardless 
of their destination address. 

When the EXOS 200 Series board is reset the controller comes up in mode - 
disconnected. The user must explicitly set the desired mode, with the 
NET_MODE call. 

8.5. ETHERNET CONTROLLER OPTION MASK 

This object defines various options, useful for testing and diagnostic purposes. 
Available options are defined by the following bit OR-able values: 

10H Alignment error - enables reception of packets even if the 
number of bits received is not a multiple of 8. 

20H CRC error - enables reception of packets even if the CRC 
check fails. 

80H Net disable - disables the Ethernet controller so that packets 
are not received or transmitted on the Ethernet. However, 
transmit requests are still processed by NX 200, and to user 
processes appear to complete successfully if an on net mode is 
selected. 

When reception of flawed packets is enabled, the actual error in a bad packet 
can be determined from the return code field in the receive reply message. 

8.6. ADDRESS SLOTS 

Address slots identify the destination addresses for which packets on the 
Ethernet should be received by this station. Each slot holds a single six-byte 
Ethernet address. Reception can be enabled or disabled individually for each 
slot. 

Slots are identified by a unique number between and 255. They are 
designated for certain purposes, according to this number, as follows: 

The null slot 

1 -252 Multicast address slots 

253 Physical address slot 

254 Universal address slot 

255 Broadcast address slot 
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The number of multicast address slots is user configurable. The default number, 
and the details of configuring NX 200, are given in the appropriate Initailization 
and Host Interface subsection; Number of Multicast Slots Field. 

Every EXOS 200 Series board is permanently assigned a physical address from 
within a contiguous block of Ethernet physical addresses allocated to Excelan. 
This address is unique over all Ethernets. When the EXOS 200 Series board is 
reset, the physical address is copied from EPROM into the physical address 
slot, where it can be read and modified. 

Processes can read and write most address slots with the NET.ADDRS call, 
and enable or disable reception for any slot with the NET_RECV call. Only valid 
multicast addresses may be written in multicast address slots. Only a valid 
physical address may be written in the physical address slot. The address in 
the broadcast slot cannot be changed. Note that writing an address in a slot 
disables reception on the slot - an explicit NET_RECV call must be made in 
order to enable reception. Enabling or disabling reception on an address slot 
does not affect the address contained in it. 

When the EXOS 200 Series board is initialized, all multicast address slots are 
empty. The physical address slot (number 253) contains the station's unique 
Ethernet address. The broadcast slot (number 255) contains the broadcast 
address. On initialization, reception is enabled on the physical and 
broadcast slots. 

Address slot numbers are used as short identifiers for the network addresses 
contained in the corresponding slots. For instance, when a packet is received, 
the receive reply message returns the address slot number whose address 
matched the destination address of the packet. Thus, a slot 253 would indicate 
that the packet arrived for the physical address - and a slot 255 would indicate 
a broadcast packet. The universal slot 254 is returned if the network is in 
promiscuous mode, or if a multicast message is received in imperfect 
filtering mode. 

8.7. NET STATISTICS 

NX supports network management functions by gathering statistics on network 
operations. The statistics appear to the user as an array of longword (32-bit) 
objects. Each object represents a counter that keeps a tally of events or some 
other value of interest, as described below. When an event counter reaches its 
maximum value, further counting on the object is inhibited until it is reset. 

Not all 32 bits of an object are necessarily used. The number of bits used by 
each object is included in the description of the objects below. The used bits 
are always the least significant bits of the object. The bits unused by an object 
are undefined, and may take any value. 

Processes can read and reset objects with the NET_STSTCS call. An object is 
referred to by its index in the array, where the index to the first object is 0. 
Multiple objects may be accessed in a single call, if they are contiguous. 
Resetting an object changes its value to 0. Resetting the EXOS 200 Series 
board resets all statistics objects - otherwise they are continuously maintained. 



8-9 



NX 200: Ethernet Interface 

Statistics objects are listed below by index number, with a complete description. 

Frames Sent No Errors - a 32-bit counter that counts the 
number of frames successfully transmitted with or without 
retries. 

1 Frames Aborted Excess Collisions - a 32-bit counter that counts 
the number of transmissions that were aborted because 16 
collisions were encountered. 

2 SQE (heartbeat) TEST error - a 32-bit counter that counts the 
number of those transmitted frames which encountered 
heartbeat absence error. (This object applicable for Ethernet 
Version 2.0 transceivers only. A jumper option is available to 
disable this feature. (See the EXOS Intelligent Ethernet 
Controller Reference Manual) 

3 Undefined - reserved for future use. 

4 Frames Received No Errors - a 32-bit counter that counts the 
number of error-free frames received. 

5 Frames Received Alignment Error - a 32-bit counter that counts 
the number of frames received with an alignment error i.e. 
frames that are not an exact multiple of an 8 bits in length. This 
statistic is maintained whether or not reception with alignment 
errors is enabled in the options mask (refer to Section 6.5.6). 

6 Frames Received CRC Error - a 32-bit counter that counts the 
number of frames received which had CRC errors. This statistic 
is maintained whether or not reception with CRC errors is 
enabled in the options mask (refer to Section 6.5.6). 

7 Frames lost - a 32-bit counter that counts the number of frames 
which would normally have been received but were lost because 
no receive buffers were available. 
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HOST INTERFACE 



9.1. INTRODUCTION 



User software on the EXOS Intelligent Ethernet Controller communicates with 
the host through a system process in the NX 200 kernel, which transmits and 
receives messages to and from the host processor. Access to this process is 
through a system mailbox associated with the host interface (0001 H). NX 200 
also provides the MEM_READ and MEM_WRITE calls which access the shared 
bus memory directly. This section describes these facilities as seen by a 
process on the EXOS Intelligent Ethernet Controller. For information about 
initializing and using the message interface from the host processor, see the 
appropriate section on Initailization and Host Interface. 

Messages are commonly used to synchronize a producer-consumer relationship 
with the host, and to exchange information with objects in host memory which 
are unknown to processes on the EXOS Intelligent Ethernet Controller. 
Typically, messages contain control information and pointers to data buffers in 
host memory, which can then be directly transferred. This approach allows user 
processes running on the EXOS Intelligent Ethernet Controller to assemble a 
data packet from scattered locations in host memory - which saves the host 
having to copy scattered blocks into one contiguous buffer for transfer 
in a message. 

9.2. HOST TRANSFER REQUEST 

In order to transfer a message to the host, a process sends a service request 
message to the system mailbox associated with the host. When the transfer is 
complete, the request message (modified according to the status of the transfer) 
is returned to a reply mailbox designated by the requesting process. Any 
number of messages can be sent to the host interface system process; they will 
be queued up and dispatched in the order received. Until the reply message is 
received, the message belongs to the system process and should not 
be modified. 

Figure 9-1 shows the format of a host transmit request/reply message. Its fields 
are explained in detail below. 

9.2.1. Link Field 

NX 200 requires the link field at the beginning of all messages. Its request and 
reply values are both undefined. NX 200 uses this field for chaining messages. 

9.2.2. Reply Mailbox Field 

The reply mailbox field identifies the mailbox to which the request message is 
returned after completion of the request. In the request message, this must 
identify an existing user mailbox. Its value in the reply message is the host 
interface system mailbox id. 
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Figure 9-1 : Host Transmit Request/Reply Message 



9.2.3. Request Code Field 

The request code field defines the request; in this case, to transmit a message, 
its value in the request message must be 0. The reply message preserves 
this value. 

9.2.4. Return Code Field 

The return code field value in undefined in the request message. In the reply 
message, it reports the status of the transmission request: 

00H Successful transfer. 

04H Transfer failed, host's receive buffer was shorter than the 
transmit length. Should this occur, the host still receives the 
message, but it is truncated. 

9.2.5. Data Length Field 

The data length field is the length, in bytes, of the data field to be transferred. 
Zero is a valid value. In the reply message, this field returns the number of 
bytes actually transferred. 

9.2.6. Data Field 

The data field is the actual message to be sent in the transmit request. The 
data can be any number of bytes as long as it lies entirely within the address 
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range 0-OFFFFH. The format of this data is defined entirely by the user. If the 
host data order conversion option is selected, NX 200 will apply any conversion 
needed for the byte string data type. The data field's contents are preserved in 
the reply message. 

9.3. HOST RECEIVE REQUEST 

In order to receive a message from the host, a process sends a service request 
message to the system mailbox associated with the host interface. When 
reception is complete, the request message (modified according to the status of 
the reception) is returned to a reply mailbox designated by the requesting 
process. Receive requests are queued up and dispatched in the order they are 
received by the host interface system process. Once the reply message is 
received, the buffer belongs to the receiving process. 

Figure 9-2 shows the format of an host receive request/reply message, which is 
very much like the transmit request/reply message. Its fields are explained in 
detail below. 
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Figure 9-2: Host Receive Request/Reply Message 



9.3.1. Link Field 



NX 200 requires the link field the beginning of all messages. Its request and 
reply values are both undefined. NX 200 uses this field for chaining messages. 
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9.3.2. Reply Mailbox Field 



The reply mailbox field identifies the mailbox to which the request message is 
returned after completion of the request. In the request message, this must 
identify an existing user mailbox. Its value in the reply message is the host 
interface system mailbox id. 

9.3.3. Request Code Field 

The request code field defines the request; in this case, to receive a message, 
its value in the request message must be 1. The reply message preserves 
this value. 

9.3.4. Return Code Field 

The return code field value in undefined in the request message. In the reply 
message, it reports the status of the transmission request: 

00H Successful transfer. 

04H Transfer failed, receive buffer was shorter than the buffer sent 
by the host. Should this occur, NX 200 still receives the 
message, but it is truncated. 

9.3.5. Data Length Field 

The data length field is the length, in bytes, of the buffer supplied in this 
message. Zero is a valid value. In the reply message, this field returns the 
number of bytes actually transferred. Zero is a possible value. 

9.3.6. Data Field 

The data field is the buffer into which data from the host will be copied. It can 
be any number of bytes as long as it lies entirely within address range 0- 
OFFFFH. The format of this data is defined by the user. If the host data order 
conversion option is selected, NX 200 will apply any conversion needed for the 
byte string data type. 

9.4. DIRECT ACCESS TO HOST SYSTEM MEMORY 

The EXOS Intelligent Ethernet Controller accesses the bus memory by mapping 
part of its own CPU's address space into bus memory addresses. The 
underlying mechanism NX 200 uses to implement the message transfer 
functions described above, is performed by mapping part of its own CPU's 
address space into bus memory addresses. User software can directly utilize 
this direct memory access mechanism without sacrificing portability by using NX 
200's MEM_READ and MEM_WRITE calls. 

These calls take an address in EXOS Intelligent Ethernet Controller memory, an 
address in host memory, and a data transfer length. NX 200 performs the 
appropriate mapping and executes the transfer. If the host data order 
conversion option is enabled, NX 200 will apply any conversion needed for the 
byte string data type. 
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9.5. HOST DATA ORDER CONVERSION 

For the convenience of protocol software running on the EXOS Intelligent 
Ethernet Controller, NX 200 provides calls which convert data between the host 
system's ordering and the CPU's native ordering. These calls, CVT_WORD and 
CVT_LWORD, work in conjunction with the host data order conversion option, 
(see the appropriate section on Initailization and Host Interface. By incorporating 
the calls in EXOS-resident software, the user's software can be made 
independent of data ordering, both on the host system, and on the EXOS 
Intelligent Ethernet Controller. 

When the host data conversion option is enabled, NX 200 sets up the 
CVT_WORD and CVT_LWORD calls according to the test pattern which the 
host system presents in the configuration message. User software running on 
the EXOS Intelligent Ethernet Controller can then use these calls to convert 
word and longword data objects passed through the data field in the standard 
host message queue, or via the MEM_READ and MEM_WRITE calls. Note that 
byte string conversion, if required, is done implicitly by the primitive transfer 
operations. CVT_WORD and CVT_LWORD do not repeat that conversion. 
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KERNEL CALL REFERENCE 



10.1. INTRODUCTION 

This section defines the specific format and usage of NX 200 kernel calls. User 
software running on the EXOS Intelligent Ethernet Controller should access all 
NX 200 services through these requests. For more information about the 
function of NX 200 kernel calls, refer to Sections 6, 7, and 8. 

Processes request NX 200 services through an INT n instruction, where n is the 
type of the desired call. Parameters are generally passed in registers, although 
some parameters can be pointers to other parameters in memory. Passing 
parameters in registers facilitates writing interfaces for different high level 
languages, which may have different calling conventions. 

Most calls return a completion code in the register AL. A negative completion 
code implies an error, and a zero or positive value implies success. Unless 
otherwise stated, only the registers used for passing parameters and results 
are modified. 

The following list summarizes the NX 200 calls, which are grouped according to 
the abstract objects on which they operate. 



PROC. 
PROC. 
PROC. 
PROC 
PROC. 
PROC. 
PROC. 
PROC. 



.CREATE 
DELETE 
.SLPCNT 
PRIOR 
TIMSLC 
STATUS 
LOCK 
UNLOCK 



MLBX_CREATE 
MLBX_DELETE 
MLBX_SEND 
MLBX_RECV 

TIME_GET 
TIME_SET 

NET_MODE 
NET.ADDRS 
NET_RECV 
NET STSTCS 



create a process 

delete a process 

read/write sleep count of a process 

read/write priority of a process 

read/write time slice of a process 

read status of a process 

lock a process 

unlock a process 

create a mailbox 

delete a mailbox 

send a message to a mailbox 

receive a message from a mailbox 

get the time 
set the time 

read/write the net mode 
read/write the net address in a slot 
enable/disable receive for a slot 
read/clear network statistics 



MEM_READ read system memory 

MEM_WRITE write system memory 

CVT_WORD convert data order of word operand 

CVT_LWORD convert data order of longword operand 

VERSION return EXOS Intelligent Ethernet Controller version number 
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The remainder of this section describes the NX 200 calls individually, in the 
order given above. A standard format is used, as follows: 

CALL NAME INTERRUPT TYPE 

Parameters: 

Specification of the call parameters 
Results: 

Specification of the call results 
Description: 

Specification of the call's purpose and effects 
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PROC_CREATE 

Parameters: 
BX: 

ES: 
CX: 



DL: 
DH: 

SI: 

Dl: 

AL: 



Results: 



AH 

BX 

Description 



the offset 
new process. 



INT 64 



part of the starting address of the 



the segment part of the starting address of the new process. 

the initial sleep count for the new process. A value of -1 
(OFFFFH) is considered infinity. 

priority of the new process (0 is the lowest, 255 is the highest). 

time slice of the new process in ticks of 20 milliseconds. A 
value of -1 (OFFH) is equivalent to an infinite time slice. 

the offset part of the address of the top of the stack for the new 
process. 

the segment part of the address of the top of the stack for the 
new process. 



completion code: 

successful. 

0F0H failed, maximum number of processes allowed already 
exists. 

undefined. 

process-id of the new process, valid only if call is successful. 



This call creates a new process with the specified parameters and 
returns its process-id. Note that the stack area can be allocated 
anywhere in user memoryi; this area should not be used for any other 
purpose. The stack pointer specified should point to the top of the new 
process stack. The initial CPU register values for the new process are 
defined as follows: 



AX 
BX 
CX 
DX 
SP 
BP 
SI: 
Dl: 



undefined. 

process-id of the process. 

undefined. 

undefined. 

offset for process top-of -stack (parameter SI). 

undefined. 

undefined. 

undefined. 
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cs 

DS 
SS 
ES 
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segment base for process code (parameter ES). 

undefined. 

segment base for process stack (parameter Dl). 

undefined. 



IP: offset for starting address (parameter BX). 

FLAGS: interrupts enabled, rest undefined. 

The successful completion of this call invokes an immediate scheduling 
decision. Thus if a process spawns another process with a zero initial 
sleep count and a higher priority than its own, control will be passed 
immediately to the new process at its starting address, before the calling 
process returns from the call. 
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PROC_DELETE 

Parameters: 

BX: process-id (0 implies calling process). 
Results: 

AL: completion code: 

successful deletion. 

0F1 H specified process does not exist. 
AH: undefined. 
Description: 



INT 65 



The specified process is deleted if it exists. It is the responsibility of the 
programmer to ensure that no harmful effects of deleting the process will occur 
(e.g. a process owning a critical section should not be deleted etc.). If the 
process being deleted was waiting in a mailbox it is first removed from the 
mailbox's process queue. If a process has invoked locks, and deletes itself, 
then any locks are removed. 
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PROC_SLPCNT 

Parameters: 



INT 66 



BX: 
CX: 

DL: 



Results: 



AL: 



AH 
BX 
CX 

Description: 



process-id (0 implies the calling process). 

new sleep count for the process, in ticks of 20 milliseconds. The value 
-1 (OFFFFH) represents infinity. This parameter is required only if a 
write is requested. 

request mask: 

01 write request bit. 

02 read request bit. 

Read and write can be requested simultaneously (DL = 03). Other bits 
in mask must be 0, or effects are undefined. 



completion code: 

successful completion. 

0F1 H failed, specified process does not exist. 

undefined. 

process-id of the specified process, not destroyed if the call fails. 

sleep count of the process just prior to this call. This result is defined 
only if the request mask (DL) had the read bit set and the call 
was successful. 



This call is used to read/write the sleep count of the specified process. If the 
write bit in the request mask (DL) is set then the current value of the sleep count 
is replaced by the specified new sleep count (CX). If the read bit in the request 
mask (DL) is set, then the the value of the sleep count prior to this call 
is returned. 

If modified, the new value of sleep count is put into effect immediately and thus 
may invoke rescheduling. If the sleep count of a blocked process is changed to 
then it is unblocked even if the process was waiting for a message to arrive at 
some mailbox. This call can be used to delay, suspend or resume a process by 
setting the sleep count to non-zero, infinity, or zero respectively. 

If this call changes the sleep count of the running process to non-zero then any 
locks in effect are canceled, regardless of errors. 
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PROC_PRIOR 

Parameters: 
BX: 

DH: 

DL: 



Results: 



AL: 



AH: 
BX: 



DH: 



Description: 



INT 67 



process-id (0 implies the calling process). 

new priority of the process (required only if write is requested), The 
lowest priority is and the highest priority is 255. 

request mask: 

01 write request bit. 

02 read request bit. 

Read and write can be requested simultaneously (DL = 03). Other bits 
in mask must be 0, or effects are undefined. 



completion code: 

successful completion. 

0F1 H failed, specified process does not exist. 

undefined. 

process-id of the specified process, if the call succeeds. Otherwise its 
value before the call is preserved. 

priority the process prior to this call. This result is defined only if the 
request mask (DL) had the read bit set and the call was successful. 



This call is used to read/write the priority of the specified process. If the write bit 
in the request mask (DL) is set, then the current priority of the process is 
replaced by the new specified priority (DH). If the read bit in the request mask 
is set, then the priority of the process prior to this call is returned. If modified, 
the new value of priority is put into effect immediately and re-scheduling is 
invoked. Thus if a process is lowering its own priority and a process with equal 
or higher priority is runnable, the call may not immediately return. 
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PROCTIMSLC 

Parameters: 
BX: 
DL: 



DH: 



Results: 



AL: 



AH: 
BX: 

DL: 

DH: 

Description: 



INT 68 



process-id (0 implies the calling process), 
request mask: 

01 write request bit. 

02 read request bit. 

Read and write can be requested simultaneously (DL = 03). Other bits 
in mask must be 0, or effects are undefined. 

new time slice of the process (required only if write is requested) in 
ticks of 20 milliseconds. A value of -1 (0FFH) represents infinity. 



completion code: 

successful completion. 

0F1H failed, specified process does not exist. 

undefined. 

process-id of the specified process if the call succeeds, otherwise 
not destroyed. 

time count the process prior to this call. This result is defined only if 
the request mask (DL) had the read bit set and the call was successful. 

time slice the process prior to this call. This result is defined only if the 
request mask (DL) had the read bit set and the call was successful. 



This call is used to read/write the time slice and time count parameters of the 
specified process. If the write bit of the request mask is set then the current 
time slice and the current time count parameters are replaced by the specified 
new time slice. If the read bit was set in the request mask then the values of 
the time slice and time count parameters are returned. Note that time count is 
the process parameter which counts down, whereas the time slice parameter is 
used to initialize time count every time it reaches zero. If modified, the new 
value of time slice is put into effect immediately and thus affects the duration 
after which a rescheduling will be invoked due to the process exhausting its 
time slice. 
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PROC_STATUS 

Parameters: 

BX: process-id (0 implies the calling process). 
Results: 

AL: completion code: 

successful completion. 

0F1 H specified process does not exist. 
AH: the status of the process: 

process running, not locked. 

1 process running, locked. 

2 process runnable. 

3 process blocked. 

BX: process-id of the specified process, not destroyed if call fails. 
Description: 

This call returns the status of the specified process. 



INT 69 



10-9 



NX 200: Kernel Call Reference 



PROCJ.OCK 

Parameters: 



INT 70 



none. 



Results: 



AL: 



AH: 



completion code: 

successful completion. 

undefined. 



Description: 



This call causes scheduling decisions to be suspended until a corresponding 
PROC_UNLOCK call is executed. A lock is said to be in effect for the duration 
of suspension. This call, in conjunction with PROCJJNLOCK, can be used to 
exclude other processes in critical sections. A process can nest locks up to 32K 
levels deep. To unlock the process, each PROC.LOCK call should be matched 
by a corresponding PROCJJNLOCK call - in a manner similar to open and 
close parentheses. Any attempt to exceed the nesting limit of 32K will result in 
an undefined action. 

If a process having locks in effect executes a call that can potentially cause the 
process to block, then all locks in effect are removed. Examples of such calls 
are MLBX_RECV with a non-zero sleep count or a PROC.SLPCNT call that 
sets the sleep count of the calling process to non-zero. 
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PROCJJNLOCK 

Parameters: 



INT 71 



none. 



Results: 



AL: 



AH: 



completion code: 

successful completion. 

undefined. 



Description: 



This call removes the effect of a single PROC_LOCK call. If, as the result of 
this call, no more locks are pending, then scheduling is resumed in a normal 
way. If any events occurred during the locked state that required a 
rescheduling, then rescheduling is invoked immediately. Every PROCJ-OCK 
call should be matched by a corresponding PROCJJNLOCK call. A 
PROCJJNLOCK call is a no-op if no locks are in effect. 
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MLBX_CREATE 

Parameters: 

BX: 

CX: 
Results: 

AL: 



INT 72 



AH 

BX 

Description 



must be -1 (OFFFFH), else effect is undefined. 

initial number of null messages, must be a non-negative number. 

completion code: 

successful completion. 

0E0H failed, maximum number of mailboxes allowed already exists. 

0E2H failed, less then zero number of initial null messages. 

undefined. 

id of the new mailbox if call successful, otherwise undefined. 



This call creates a new mailbox and returns its id. The specified number of null 
messages are enqueued in the mailbox. Note that if the mailbox is being used 
as a semaphore, then this allows creating a semaphore with a specified initial 
count. The process and regular message queues are always empty 
when initialized. 
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Parameters: 



BX: 



Results: 



AL: 



AH 
BX 

Description 
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MLBX DELETE 



INT 73 



mailbox-id. 

completion code: 

successful deletion. 

0E1H failed, specified mailbox does not exist. 

undefined. 

undefined, not destroyed if the call fails. 



The specified mailbox is deleted. If any processes are blocked on this mailbox, 
then they are unblocked and resumed with the appropriate error code. Any 
unreceived messages in the mailbox are lost. It is the programmer's 
responsibility to ensure that deleting a mailbox has no harmful effects. The user 
should not delete a system mailbox. 
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MLBX.SEND 

Parameters: 
BX: 
SI: 
ES: 



INT 74 



Results: 



AL: 



AH: 



Description: 



mailbox -id. 

offset part of the message address. OFFFFH specifies a null message. 

segment part of the message address. This must be 0, or effect 
is undefined. 

completion code: 

successful completion. 

0E1H failed, specified mailbox does not exist. 

0E4H failed, invalid request for a system mailbox. 

0E5H failed, improper buffer (message buffer segment not 0). 

undefined. 



This call sends the specified message to the specified mailbox. If one or more 
processes are waiting in the mailbox then the first process is unblocked and 
resumed, having received this message. If a process is unblocked then a 
rescheduling is invoked immediately. 

The message must lie entirely within the address range 0-OFFFFH. The first 
field of the message should be a 32-bit link field available for use by NX 200. If 
the specified mailbox is a system mailbox then the message must be formatted 
according to the specifications of the corresponding system process. 

A regular message is appended at the end of all other regular messages in the 
mailbox but in front of all null messages, if any. A null message is appended at 
the end of all messages in the mailbox. If only null messages are used then this 
call is equivalent to a V operation on a semaphore. 
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MLBX RECV 



Parameters: 



INT 75 



BX: 
CX: 



Results: 



AL: 



AH: 



SI: 



ES: 



mailbox-id. 

sleep count, in ticks of 20 milliseconds. A value of -1 (OFFFFH) 
represents infinity. 



completion code: 

successful. 

0E1H failed, specified mailbox does not exist. 

0C0H failed, specified sleep count exhausted. 

0E3H failed, the mailbox is being deleted. 

undefined. 

offset of the message address if the call is successful, otherwise 
undefined. A value of -1 (OFFFFH) indicates a null message. 

segment part of the message address if the call is successful, 
otherwise undefined. NX 200 always returns 0. 



Description: 



If the mailbox's message queue contains any messages, either regular or null, 
then this call returns the address of the first message in the queue. 

If there are no pending messages and the sleep count is non-zero, then the 
calling process is blocked and appended at the end of the mailbox's process 
queue. The sleep count of the process is set to the specified value. When a 
message becomes available, the call returns its address, as above. If the sleep 
count of the blocked process counts down to zero, or is explicitly set to zero by 
a PROC_SLPCNT call, before it receives a message, then the process is 
unblocked and returns from this call with the error code 0C0H. 

Note that if the sleep count was specified to be zero then the process effectively 
does not block and returns immediately with the error code 0C0H. By specifying 
the sleep count to be infinity, finite non-zero, or zero, a process can choose to 
wait forever, wait for a finite time interval, or not wait at all to receive a 
message. 

If this call is made with a non-zero sleep count, then any locks in effect are 
canceled, regardless of any errors the call may return. 
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T!ME_GET 

Parameters: 
CX: 
Dl: 

ES: 

Results: 

AL: 

AH 

CX 

Description 



INT 76 



number of 16-bit words of clock value to be returned. 

offset part of the memory buffer address to which the clock value will 
be copied. 

segment part of the memory buffer address to which the clock value 
will be copied. 



completion code: 

successful. 

undefined. 

number of words actually copied. 



This call copies the specified number of 16-bit words of the clock value into the 
specified memory buffer. The least significant word of the clock occupies the 
lowest address of the buffer. If the specified number of words to be copied is 
more than the actual number of the words in the clock, then the extra buffer 
remains unused The clock is a 64-bit counter that is incremented every 20 
milliseconds. When the EXOS Intelligent Ethernet Controller is reset, the clock 
is initialized as zero. 
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TIME.SET 

Parameters: 
CX: 
Dl: 

ES: 

Results: 



INT 77 



number of words to be written. 

offset part of the memory buffer address from which the new clock 
value will be copied. 

segment part of the memory buffer address from which the new clock 
value will be copied. 



AL: 


completion code: 




successful. 


AH 


undefined. 


CX 


number of words actually written 


Description 





This call copies the specified number of words from the specified buffer into the 
clock counter, starting from the least significant word. If the specified number of 
words to copy is greater than the number of words in the clock, then the 
remainder are not used. The clock is a 64-bit counter that is incremented every 
20 milliseconds. 
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NETJUODE 

Parameters: 
CL: 



DL: 



DH: 



Results: 



AL: 

AH: 
CL: 

DH: 



INT 78 



options mask, which defines various controller options. Available 
options are defined by the following bit OR-able values: 

10H alignment error - enables reception of packets even if the 
number of bits received is not a multiple of 8. 

20H CRC error - enables reception of packets even if the CRC 
check fails. 

80H net disable - disables the Ethernet controller so that packets 
are not received or transmitted on the Ethernet. However, 
transmit requests are still processed by NX 200, and to user 
processes appear to complete successfully if an on net mode 
is selected. 

All other bits are undefined and must be 0. This parameter is required 
only if a write is requested. 

request mask: 

01 write request bit. 

02 read request bit. 

Read and write can be requested simultaneously (DL = 03). Other bits 
in mask must be 0, or effects are undefined. 

the new mode of the Ethernet controller. Possible values are: 

00H off net. Disconnect from the net. 

01 H on net, perfect filtering. Connect to net, perfect filter for 
multicast addresses. 

02H on net, imperfect filtering. Connect to net, only hardware filter 
for multicast addresses. 

03H on net, promiscuous mode. Connect to net, receive all 
packets. 

This parameter is required only if a write is requested. 

completion code: 

successful. 

undefined. 

options mask prior to this call. This result is defined only if the request 
mask (DL) had the read bit set. 

mode prior to this call. This result is defined only if the request mask 
(DL) had the read bit set. 
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Description: 

This call is used to read/write the network controller mode and options mask 
parameters. If the write bit in the request mask (DL) is set, then the specified 
mode is written. Only the modes defined above should be used. Other modes 
are reserved for Excelan and their effects are not defined. The options mask 
defines the errors that are acceptable for the packets. If the read bit in the 
request mask is set then the mode and options mask of the controller prior to 
this call are returned. 

Note: 

If NETJvlODE was called in promiscuous mode (DH = 03), the NETJRECV call 
will not disable broadcast messages. 
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NET.ADDRS 




Parameters: 




DL: 


request mask: 




01 write request bit. 




02 read request bit. 



INT 79 



Results: 



DH: 

Dl: 
ES: 

AL: 



AH: 



DL: 



Description: 



Read and write can be requested simultaneously (DL 
in mask must be 0, or effects are undefined. 



03). Other bits 



address slot number. Designates the address slot which this request 
will work on. This can be the physical address slot (253) or any 
multicast address slot (between 1 and the limit defined by 
configuration). 

offset part of the address of a six byte array. If a write is requested, 
then this array must contain the network address to be written. 

segment part of the address of a six byte array described above. 



completion code: 

successful completion. 

0D1 H the specified slot does not exist or access is not permitted. 

0D3H improper address. Multicast slots can only take multicast 
addresses and the physical slot can only take a physical 
address. Attempting to write the broadcast slot (number 255) 
results in this error. 

undefined. 

If bit 3 (mask value 8) is set, then the address slot contained a valid 
address prior to this call, otherwise the slot was empty. All other bits 
are undefined. This result is valid only if a read was requested. 



This call is used to read/write an address in the specified address slot. If the 
write bit is set in the request mask, then the network address is copied into the 
specified slot from the array whose address is specified in Dl, ES. If the read bit 
was set in the request mask then the network address in the specified address 
slot prior to this call is copied into the array whose address is specified in Dl, 
ES. The address read is valid only if the slot was not empty prior to this call 
(DL). If a network address to be written is invalid, the write does not occur, and 
the address in the slot prior to the call is preserved. Writing an address into a 
slot disables receive on that slot. The call NET_RECV must be explicitly used to 
enable receive on the slot. 

Address slot 253 is reserved for the physical address and address slot 255 is 
reserved for the broadcast address. Thus the user can find the physical 
address by reading the address in slot 253. 



10-20 



NX 200: Kernel Call Reference 



NET.RECV 






Parameters: 






DL: 


request mask: 




01 


write request bit. 




02 


read request bit. 




04 


enable receive bit. 



INT 80 



Read and write can be requested simultaneously (DL = 03). Other bits 
in mask must be 0, or effects are undefined. 

DH: address slot number. Designates the address slot which this request 
will work on. This can be the physical address slot (253), the 
broadcast slot (255), or any multicast address slot (between 1 and the 
limit defined by configuration). 



Results: 



AL: completion code: 

successful completion. 

0D1 H the specified slot does not exist or access is not permitted. 

0D2H the address slot is empty. 
AH: undefined. 

DL: If bit 2 (mask value 4) is set, then the receive was enabled for this slot 

prior to this call, otherwise it was disabled. All other bits are undefined. 
This result is defined only if read was requested. 



Description: 



This call is used to read/alter the receive status of an address slot. If the write 
bit is set in the request mask, then the receive is enabled or disabled depending 
on bit 2 of the request mask. If bit 2 (mask = 4) is set, then receive is enabled, 
otherwise it is disabled. If the read bit was set in the request mask then the 
receive status of the address slot prior to this call is returned. 



Note: 



If NET_MODE was called in promiscuous mode (DH 
will not disable broadcast messages. 



03), the NET.RECV call 
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NET_STSTCS 

Parameters: 
DL: 



Results: 



CX: 

SI: 

Dl: 

ES: 
AL: 



CX: 
Description: 



INT 81 



request mask: 

01 write request bit. 

02 read request bit. 

Read and write can be requested simultaneously (DL = 03). Other bits 
in mask must be 0, or effects are undefined. 

number of objects to be read/reset. 

index into the statistics objects array. 

offset part of the buffer address to which the statistics objects are to be 
copied. 

segment part of the buffer address to which the statistics objects are to 
be copied. 



completion code. 

0: successful. 

the actual number of objects read/reset. 



This call reads/resets the statistics objects. Net statistics are an array of 32-bit 
objects, described in Section 8.7. If the read bit is set in the request mask then 
the statistics objects starting at the index specified by SI are copied into the 
array specified by Dl, ES. The number of objects to be copied is specified in 
CX. If the write bit is set in the request mask, then the number of objects 
specified by CX, starting at the index specified by SI, are reset to zero. The 
actual number of objects read/reset is returned in CX. If the index specified in 
SI is out of range, then no objects are read/reset. 
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MENLREAD 

Parameters: 
CX: 

DX: 
SI: 
Dl: 
ES: 
Results: 

AL: 

AH: 
Description: 



INT 82 



number of bytes to be read. This number must be less than or equal to 
64K-16. 

high-order word of the address in system memory. 

low-order word of the address in system memory. 

offset part of the address in EXOS front-end processor memory. 

segment part of the address in EXOS front-end processor memory. 

completion code: 
successful, 

undefined. 



This call copies the specified number of bytes from the specified address in 
system memory to the specified address in EXOS front-end processor memory. 
If the host data order conversion option is selected (refer to Section 2.3, 3.3, 
4.3, or 5.3, as applicable to the specific system bus) then any required 
conversion for the byte string data type will be done. 

Note that this call may potentially block the user process, and as a result, all 
locks in effect would be removed. 
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MEM_WRITE 

Parameters: 
CX: 

DX: 
SI: 
Dl: 
ES: 
Results: 

AL: 

AH: 
Description: 



INT 83 



number of bytes to be written. This number must be less than or equal 
to64K-16. 

high-order word of the address in system memory. 

low-order word of the address in system memory. 

offset part of the address in EXOS front-end processor memory. 

segment part of the address in EXOS front-end processor memory. 

completion code: 
successful, 

undefined. 



This call copies the specified number of bytes from the specified address in 
EXOS front-end processor memory to the specified address in system memory. 
If the host data order conversion option is selected (refer to Section 2.3, 3.3, 
4.3, or 5.3, as applicable to the specific system bus) then any required 
conversion for the byte string data type will be done. 

Note that this call may potentially block the user process, and as a result, all 
locks in effect would be removed. 
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VERSION 

Parameters: 



Results: 



none. 

AL: 
AH: 

CX 
DX 



Description 



INT 84 



always 0. 

undefined for NX Version numbers less than 4.0; EXOS context 
otherwise. 

version of NX 200. 

version of the EXOS Intelligent Ethernet Controller hardware. 



This call returns the version number of the EXOS Intelligent Ethernet Controller 
hardware and NX 200. Version numbers have the form X.Y, where the lower 
byte (CL or DL) contains the ASCII value of X and the higher byte (CH or DH) 
contains the ASCII value of Y. 

If the NX 200 version number returned in CX is less than 4.0, then AH contents 
are undefined. If the NX 200 version number returned in CX is equal to or 
greater than 4.0, then AH contains the EXOS context. For different controllers 
the context value is as follows; 



Controller 

EXOS 201 
EXOS 202 
EXOS 203 
EXOS 204 



Context Value 

01 
02 
03 
04 
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CVT_WORD 

Parameters: 



INT 85 



BX: word operand to be converted. 



Results: 

BX: 
Description: 



converted word operand. 



If the host data order conversion option is selected, (refer to Section 2.3, 3.3, 
4.3, or 5.3, as applicable to the specific system bus) then this call performs any 
required conversion for the word data type. It converts a word in the host 
system's native ordering to the 80186 CPU's native ordering, and vice versa. 
The only conversion relevant to this data type is byte swapping; its necessity is 
determined by the same test pattern which enables conversion for message 
queue data structures. CVT_WORD assumes that any conversion required for 
the byte string data type has already been performed on the operand. If the 
host data order conversion option is not selected, then the operand is returned 
without modification. 
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CVT_LWORD 

Parameters: 
BX: 
DX: 

Results: 

BX 
DX 



INT 86 



first word of longword operand to be converted, 
second word of longword operand to be converted. 

first word of converted longword operand, 
second word of converted longword operand. 



Description: 

If the host data order conversion option is selected (refer to Section 2.3, 3.3, 
4.3, or 5.3, as applicable to the specific system bus) then this call performs any 
required conversion for the longword data type. It converts a longword in the 
host system's native ordering to the 80186 CPU's native ordering, and vice 
versa. Possible conversions are word swapping, byte swapping, or both. Note 
that all possible conversions are symmetrical, and reflexive. Therefore the order 
of first and second word parameters to this call is not important, as long as user 
software treats the result consistently. 

Necessary conversions are determined by the same test pattern which enables 
conversion for message queue data structures. CVT_LWORD assumes that 
any conversion required for the byte string data type has already been 
performed on the operand. If the host data order conversion option is not 
selected, then the operand is returned without modification. 
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Chapter 11 
INITIALIZING AND DOWNLOADING FROM THE ETHERNET 

11.1. INTRODUCTION 

The EXOS Intelligent Ethernet Controller can be configured and downloaded 
from its Ethernet interface in a manner quite similar to initialization by a host 
processor. This permits its use as a system master where the system's design 
does not include another CPU card, or it provides a convenient way to bootstrap 
diskless workstations. NX 200 firmware includes a simple protocol which 
supports the network bootstrap function. This section describes the network 
bootstrap protocol and provides information sufficient to implement a 
corresponding bootstrap server. 

Network bootstrap is initiated either by a jumper option (see the EXOS 
Intelligent Ethernet Controller Reference Manual) upon reset, or explicitly by a 
host system during configuration (refer to the Configuration Message Format 
section, in the appropriate Initialization and Host Interface chapter). In all cases, 
the EXOS Intelligent Ethernet Controller does the following: 

1 . Finds a network bootstrap server on the Ethernet. 

2. Builds up a session with the boot server. 

3. Processes commands, including configuration and software 
download, received from the boot server. 

4. Executes the downloaded code. 

The network bootstrap protocol is based on request and reply messages which 
are encapsulated in standard Ethernet packets. The Ethernet type field 
identifies net boot packets as belonging to an Excelan protocol type. Another 
sub-type field designates the EXOS Intelligent Ethernet Controller network 
bootstrap protocol specifically. 

11.2. NETWORK BOOTSTRAP PROTOCOL DESCRIPTION 

Figure 1 1 -1 shows a state diagram of the network bootstrap protocol, both for 
client (the EXOS Intelligent Ethernet Controller) and for boot server. In this 
diagram, states are represented as capitalized names enclosed in circles. State 
transitions appear as solid lines, with an arrow at one end to indicate the 
direction of the transition. Ethernet messages are shown as broken double 
lines, with the name of the message imbedded. An arrow at one end indicates 
the direction of transmission. Reception of an Ethernet message defines an 
event, and usually triggers a state transition. Note that transmission by one 
party does not guarantee reception by the other. 

Whenever the event driving a state transition is a timeout, the line includes a C 
language expression in parentheses, such as "(f<FR)," or "(f> = FR)." The 
lower-case identifiers to the left in such an expression are counters, and refer to 
the number of timeouts of this kind which have occurred so far, while the upper- 
case constants to the right refer to the maximum number of retries permitted for 
this timeout. When a timeout occurs, the state transition taken will be that for 
which the expression is true. The counters are initialized and modified 
according to specific events, usually packet transmission or arrival. The 
appropriate action is shown as a C language statement enclosed in curly braces 
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f = find request retries 
FR = f i nd retry limit = 16 
s = select request retries 
SR = select retry limit = 16 
c = command request retries 
CR = command retry limit 



*-START NETBOOT 
{ 1=0 s=0} 

===F I ND=REQUEST=== 
{t++| 




(s<SR) 
(S>=SR) 
( f>=FR 
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SELECT=REPLY=== 
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— ( f<FR) 
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COMMAND=REQUEST= 
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'command 



= =COMMAND = REPLY= = 
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I EXECUTE I 




EXOS BOARD STATES 
Figure 11-1: State Diagram of Network Bootstrap Protocol 



BOOT SERVER STATES 
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below the associated event. For example, "{f+ + }" increments the FIND request 
counter whenever the client transmits that message. 

EXOS Intelligent Ethernet Controller states, shown to the left of the diagram, are 
as follows: 

RESET denotes that the EXOS Intelligent Ethernet Controller has been 
reset, but has not yet attempted a network bootstrap. 

FIND REPLY WAIT denotes that the EXOS Intelligent Ethernet 
Controller has sent one or more find request messages, and not yet 
received a reply to the most recent one. 

SELECT REPLY WAIT denotes that the EXOS Intelligent Ethernet 
Controller has sent one or more SELECT request messages, and not 
yet received a reply to the most recent one. 

COMMAND REQUEST WAIT denotes that the EXOS Intelligent 
Ethernet Controller has received a SELECT reply message, and is now 
awaiting a command request message from the selected boot server. 

EXECUTE denotes that the EXOS Intelligent Ethernet Controller has 
received a valid execute request message, and sent the corresponding 
reply message. It now begins to execute the code which has 
presumably been downloaded by the boot server. 

ABORT denotes that the network bootstrap attempt has failed, after 
exhausting a specified number of retries (16 by default). The EXOS 
Intelligent Ethernet Controller displays an error code on the status LED 
until it is reset. 

Boot server states for a straightforward implementation (shown to the right of 
the diagram) are as follows: 

BOOT REQUEST WAIT denotes that the boot server is prepared to 
build a boot session with some EXOS Intelligent Ethernet Controller 
client. In this state, it responds both to find request and SELECT 
request messages. 

COMMAND REPLY WAIT denotes that the boot server has received a 
SELECT request message, and sent back a SELECT reply message, 
thereby establishing a boot session with some EXOS Intelligent Ethernet 
Controller client. The boot server proceeds directly to send a command 
request message, and then awaits a command reply message from the 
client associated with this session. 

State transitions occur only in response to some asynchronous event. In the 
network boot protocol, two basic types of event occur: arrival of a message on 
the Ethernet, or a timeout while waiting for some message. An exception is the 
START NETBOOT event, which actually encompasses two circumstances 
(neither of which involves Ethernet messages) that can initiate the network 
bootstrap procedure. 

The network bootstrap protocol is based on three general types of request 
message. For each request message, the protocol defines a reply message 
whose format is identical. These message pairs are as follows: 

1. The EXOS Intelligent Ethernet Controller broadcasts the FIND 
request message to discover the existence and address of 
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bootstrap servers on the network. All bootstrap servers which 
receive this message send back a FIND reply message. 

2. The EXOS Intelligent Ethernet Controller sends the SELECT 
request message to the one bootstrap server which it wants to 
control the subsequent bootstrap process. The selected bootstrap 
server acknowledges its readiness to perform this role by sending 
back the SELECT reply message. 

3. The bootstrap server can use several different COMMAND request 
messages to configure the EXOS Intelligent Ethernet Controller, 
download code, upload its memory contents, and begin execution. 
For each request, the EXOS Intelligent Ethernet Controller returns a 
COMMAND reply message to the bootstrap server. 

A normal network bootstrap (where no packets are lost, all necessary resources 
are available, and nobody crashes) proceeds as follows, from the EXOS 
Intelligent Ethernet Controller's point of view: 

1. The EXOS Intelligent Ethernet Controller initiates the network 
bootstrap procedure upon either a hardware or software reset, if the 
net boot jumper is selected. If the net boot jumper is not selected, 
it can still initiate a network bootstrap upon initialization by the host 
system. In any case, it gets the ball rolling by broadcasting a FIND 
request message. This message contains: 

a. The version number of the network bootstrap protocol which 
the EXOS Intelligent Ethernet Controller supports. 

b. The number of buffers available on the EXOS Intelligent 
Ethernet Controller to receive incoming network bootstrap 
COMMAND request messages. 

c. The length of the buffers described above. 

d. The Ethernet address of the EXOS Intelligent Ethernet 
Controller (this is a separate field from the standard Ethernet 
source address field). 

e. A message ID, which uniquely identifies the request message. 

f. A timeout parameter, which tells the boot servers how long the 
EXOS Intelligent Ethernet Controller will wait for a reply 
message before re-trying or giving up. 

g. A configuration message, which describes the current 
configuration of the EXOS Intelligent Ethernet Controller. This 
is nearly identical to the configuration reply message returned 
during initialization by a host (see the Configuration Message 
Format section in the appropriate INITIALIZATION and HOST 
INTERFACE chapter). 

After sending the request message, the EXOS Intelligent Ethernet 
Controller enters the FIND REPLY WAIT state. 

2. Before its FIND reply timeout expires, the EXOS Intelligent Ethernet 
Controller should receive a FIND reply message from at least one 
qualified bootstrap server. If more than one is received, the EXOS 
Intelligent Ethernet Controller selects the first to arrive, and discards 
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subsequent FIND reply messages. This message provides the 
following information: 

a. The Ethernet address of the bootstrap server (as above, this is 
a separate field from the standard Ethernet source address 
field). 

b. A timeout parameter, which specifies how long the EXOS 
Intelligent Ethernet Controller should wait for the boot server's 
SELECT reply message. 

Immediately upon receiving a legitimate FIND reply message, the 
EXOS Intelligent Ethernet Controller sends a SELECT request 
message to the bootstrap server whose address was contained in 
the reply message. This tells the designated bootstrap server that it 
is responsible for bootstrapping this EXOS Intelligent Ethernet 
Controller client. The SELECT request message contains exactly 
the same information as the FIND request message, except 
possibly for the timeout parameter. The EXOS Intelligent Ethernet 
Controller specifies its current effective timeout value in this field. 
After sending the SELECT request message, the EXOS Intelligent 
Ethernet Controller enters the SELECT REPLY WAIT state. 

3. Before its SELECT reply timeout expires, the EXOS Intelligent 
Ethernet Controller should receive a SELECT reply message from 
the selected bootstrap server. This contains the same information 
as the FIND reply message, except possibly for the timeout 
parameter, which now tells the EXOS Intelligent Ethernet Controller 
how long to wait before giving up on receiving a COMMAND 
request message from the boot server. Reception of the SELECT 
reply message establishes a bootstrap session, and the EXOS 
Intelligent Ethernet Controller enters the COMMAND REQUEST 
WAIT state. 

4. Before its COMMAND request timeout expires, the EXOS Intelligent 
Ethernet Controller should receive a COMMAND request message 
from the selected bootstrap server. When a command arrives, the 
EXOS Intelligent Ethernet Controller processes the command and 
returns a COMMAND reply message to the bootstrap server, 
informing it of the command's result. After sending the reply 
message, the EXOS Intelligent Ethernet Controller normally returns 
to the COMMAND REQUEST WAIT state. However, if the 
command was an EXECUTE request, the bootstrap session is 
terminated (as far as the EXOS Intelligent Ethernet Controller is 
concerned) and the EXOS 200 Series board proceeds to execute 
the code which has presumably been downloaded. 

While the description above specifies exactly how the EXOS Intelligent Ethernet 
Controller will behave during a network bootstrap session, the bootstrap server's 
behavior is largely up to its implementor. The network bootstrap protocol is 
implemented with a typical bootstrap server model in mind, such as is shown in 
the state diagram. A real boot server might support more than one boot session 
simultaneously; the diagram shows only the context of a single boot session. 

Note also that this diagram describes only the case where the EXOS Intelligent 
Ethernet Controller provides just one receive buffer for processing net boot 
commands. Therefore it assumes that only one command may be outstanding. 
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Future releases of NX 200 may permit pipelined boot command processing by 
supplying multiple buffers. While this model for a boot server will still work when 
more buffers are available, it will not derive any performance advantage. At any 
rate, from the boot server's point of view, net boot proceeds as follows: 

1. The bootstrap server starts in the BOOT REQUEST WAIT state, 
awaiting the arrival of either a FIND request message or a SELECT 
request message. Upon reception of a FIND request message, the 
boot server examines relevant information in this message, such as 
the protocol version. If the boot server decides that it can service 
the client which the request identifies, it sends back a FIND reply 
message to the address contained in the request. This message 
tells the client the boot server's address and how long a timeout it 
should use when waiting for subsequent messages from the boot 
server. The boot server then returns to the BOOT REQUEST WAIT 
state. 

2. When the bootstrap server receives a SELECT request message, it 
records the information it will need to boot the client, and returns a 
SELECT reply message. Once again, this contains a timeout 
parameter which tells the client how long to wait for subsequent 
messages. At this point, a bootstrap session has been established, 
so far as the boot server is concerned. 

3. After sending a SELECT reply message, the bootstrap server 
proceeds immediately to send COMMAND request messages to the 
client. After sending any COMMAND request message, the 
bootstrap server enters the COMMAND REPLY WAIT state. 

4. Before its COMMAND reply timeout expires, the bootstrap server 
should receive a COMMAND reply message. It then sends the next 
COMMAND request message and re-enters the COMMAND 
REPLY WAIT state. However, if the COMMAND reply message 
was that of an execute request, then the bootstrap session is 
terminated and the boot server returns to the BOOT REQUEST 
WAIT state. 

The description so far of the network bootstrap protocol has been simplified 
somewhat by ignoring considerations such as spurious messages or lost 
packets. However, these things can happen. Therefore, the protocol provides 
mechanisms which can accommodate errors during, and ensure completion of, 
the network bootstrap process. 

Once the boot server's address is established, the EXOS Intelligent Ethernet 
Controller will ignore messages from other sources. Another general principle 
the EXOS Intelligent Ethernet Controller obeys is to ignore any message types it 
does not expect in its current state. For instance, COMMAND request 
messages will have no effect if the EXOS Intelligent Ethernet Controller is still in 
the SELECT REPLY WAIT state. A straightforward boot server implementation 
would also follow these rules. 

The network bootstrap protocol uses a timeout/retry mechanism to recover from 
lost messages and various catastrophic circumstances. In any state where the 
EXOS Intelligent Ethernet Controller is waiting for some message to arrive, if the 
message does not arrive within some specified real-time interval (3000 
milliseconds by default), the EXOS Intelligent Ethernet Controller will timeout. 
Depending on circumstance, it may then abort or retry, possibly entering a 
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different state. The EXOS Intelligent Ethernet Controller maintains two counters 
which help determine the appropriate action. The FIND request counter is 
reset by the START NETBOOT event, and is incremented every time a FIND 
request message is transmitted. The SELECT request counter is reset when a 
FIND reply message is received, and is incremented every time a SELECT 
request message is transmitted. State transitions which occur on timeout 
events are described below, according to the state before timeout: 

FIND REPLY WAIT: When a timeout occurs, the EXOS Intelligent 
Ethernet Controller normally transmits another FIND request message 
and returns to the FIND REPLY WAIT state. However, if the FIND 
request counter shows that 16 FIND request messages have already 
been sent, then the net boot attempt is aborted and the EXOS Intelligent 
Ethernet Controller enters the ABORT state. The EXOS intelligent 
controller will then display the appropriate error code on its status LED 
(see the EXOS Intelligent Ethernet Controller Hardware Reference 
Manual). If the net boot was instigated by a host system, then the 
appropriate error code is also written into the configuration message's 
completion code field in host memory (see the appropriate Configuration 
Completion Code Field section in INITIALIZATION and HOST 
INTERFACE). 

SELECT REPLY WAIT: When a timeout occurs, the EXOS Intelligent 
Ethernet Controller normally transmits another SELECT request 
message and returns to the SELECT REPLY WAIT state. However, if 
the SELECT request counter shows that 16 SELECT request messages 
have already been sent, then the EXOS Intelligent Ethernet Controller 
transmits another FIND request message and returns to the FIND 
REPLY WAIT state. If the FIND request counter also shows that 16 
FIND request messages have already been sent, then the net boot 
attempt is aborted, as above. 

COMMAND REQUEST WAIT: When a timeout occurs, the EXOS 
Intelligent Ethernet Controller normally transmits another FIND request 
message and returns to the FIND REPLY WAIT state. However, if the 
FIND request counter shows that 16 FIND request messages have 
already been sent, then the net boot attempt is aborted, as described 
above. 

Timeout processing in the bootstrap server is up to the implementor. In the 
typical implementation which the state diagram describes, only the COMMAND 
REPLY WAIT state can generate a timeout event. The timeout period, and the 
number of retries allowed, are dependent on the implementation. Typically, the 
timeout period multiplied by the number of retries allowed should not greatly 
exceed the EXOS Intelligent Ethernet Controller's COMMAND REQUEST WAIT 
timeout (which can be specified by the boot server in the SELECT reply 
message). 

During a network bootstrap attempt, it is possible that either the client or server 
could receive messages generated during some prior network bootstrap attempt 
gone awry. For instance, if the SELECT reply message is lost, then a boot 
server would still assume that a session had been established, and would 
persist in retrying on its first COMMAND request message. Meanwhile, the 
EXOS Intelligent Ethernet Controller might have established a new boot session. 
Some means is needed to distinguish between messages belonging to the 
legitimate boot session and the defunct boot session. For this purpose, the 
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network bootstrap protocol supports the concept of message IDs and, once a 
session is established, session IDs. 

The EXOS Intelligent Ethernet Controller generates a message ID field for both 
FIND request and SELECT request messages. This ID guards the EXOS 
Intelligent Ethernet Controller against spurious message reception up to the 
point that a network bootstrap session is established. The EXOS Intelligent 
Ethernet Controller's message ID generation algorithm guarantees that it will be 
unique in each and every message from the time the board is reset until it is 
reset again. Furthermore, the field contains a random component which makes 
makes ID collision very unlikely even after a reset occurs. As described above, 
the boot server is expected to copy the message ID from FIND and SELECT 
request messages into their corresponding reply messages. 

When the boot server establishes a session (by returning the SELECT reply 
message), it is responsible for creating a unique 12-byte session ID value, which 
it passes to the EXOS Intelligent Ethernet Controller in the SELECT reply 
message. In all subsequent COMMAND request messages, the boot server 
should write this value into the first 12 bytes of the 16-byte message ID field. 
When the EXOS Intelligent Ethernet Controller receives a COMMAND request 
message, it ignores it unless the first 12 bytes of the message ID field agree 
with the value it received in the SELECT reply message. When the EXOS 
Intelligent Ethernet Controller prepares a reply message, it copies the entire 
message ID field from the corresponding request message. The remaining 4 
bytes at the end of the ID field can be used for any purpose which suits the boot 
server - typically message serialization. 

11.3. DATA TRANSMISSION ORDER 

This section defines the order of transmission for data objects which are known 
to the network bootstrap protocol implemented by NX 200. Network bootstrap 
servers must obey these conventions when transmitting messages to the EXOS 
Intelligent Ethernet Controller, and should observe them when interpreting 
messages received from the EXOS Intelligent Ethernet Controller. 

The fields defined by the Ethernet specification for the standard data link layer 
frame format (destination address, source address, type, and frame check 
sequence) are, of course, transmitted in their standard order. The Ethernet 
specification also defines how the contents of a packet's data field (which 
contains all network bootstrap message contents) are to be transmitted, but only 
in terms of bit significance. For each byte in a packet's data field, the Least 
Significant Bit (LSB) is transmitted first, and the Most Significant Bit (MSG) last. 

The byte ordering of multi-byte data objects in network bootstrap messages is 
defined solely by the network bootstrap protocol. This follows a simple rule. All 
data objects are transmitted as though stored in memory according to the 80186 
CPU's native order, and then transmitted one byte at a time, starting at the 
lower memory address. This is the transmission order which naturally occurs 
when the network bootstrap protocol is implemented on the EXOS Intelligent 
Ethernet Controller. When implementing a bootstrap server based on a different 
CPU architecture, programmers should be careful to observe this ordering. 

Note that the EXOS Intelligent Ethernet Controller host data order conversion 
option does not apply to the contents of network bootstrap messages. However, 
the option may be enabled as usual by the CONFIGURE request message. 
Simply set up the test pattern field as it would have been written by the system 
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being bootstrapped. Data conversion will then work on all messages passed 
between the client EXOS Intelligent Ethernet Controller and its host processor. 
The rest of the CONFIGURE request message, and all other messages, will still 
be interpreted according to 80186 data ordering. 

11.4. NETWORK BOOTSTRAP PROTOCOL MESSAGE HEADER 

Network bootstrap request and reply messages share a common header format, 
shown in Figure 1 1 -2. The following paragraphs describe its individual fields in 
detail. 
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Figure 11-2: Network Bootstrap Protocol Request/Reply Message Header 



11.4.1. Subtype Field 

The subtype field identifies specific Excelan protocol types. The network 
bootstrap protocol's type is 0; all request and reply messages must contain this 
value. 

11.4.2. Message ID Field 

The message ID field is used before a session is established to associate 
request messages with the corresponding reply messages. The EXOS 
Intelligent Ethernet Controller generates unique message ID numbers for the 
FIND and SELECT request messages, and the boot server simply copies these 
numbers into the corresponding reply messages. Once a session is established, 
this field identifies all request and reply messages as belonging to that session, 
and can be used to serialize messages. The boot server generates the session 
ID number used in all subsequent COMMAND request and reply messages. 
The following sections will explain this field in more detail. 
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11.4.3. Request Code Held 

The request code field identifies the particular request or reply contained in a 
network bootstrap message. Values are as follows: 






DOWNLOAD 


1 


UPLOAD 


2 


EXECUTE 


3 


CONFIGURE 


4 


FIND 


5 


SELECT 



The same code is used for both request and reply messages. They are 
distinguished from each other by context. 

11.4.4. Reply Code Field 

The reply code field returns the result of a request. It must be in request 
messages. Its meaning in reply messages will be explained in the individual 
message descriptions below. 

11.4.5. Message Length Field 

The message length field defines the number of bytes beyond its own position in 
the Ethernet packet containing the request or reply message. As usual, this 
should not include the CRC field's length. 

11.4.6. Request-Specific Fields 

Beyond the message length field, the remainder of each request message is 
defined according to the purpose of the request. These fields are described 
below, in the individual message descriptions. 

11.5. MESSAGE ENCAPSULATION 

Request and reply messages are encapsulated in the data field of a standard 
Ethernet packet, as shown in Figure 11-3. 

The EXOS Intelligent Ethernet Controller places the physical address of a boot 
server in the destination address field, except in the FIND request message, 
where it contains the Ethernet broadcast address. The boot server should 
always place the physical address of a client EXOS Intelligent Ethernet 
Controller in the destination address field. 

The source address field always contains the physical address of the party 
which sent the message. 

The type field should always contain the Excelan protocol type, which in 
Ethernet parlance is: 

80-10 

The value above is given in hexadecimal notation, and should be transmitted 
left-most byte first. On the EXOS Intelligent Ethernet Controller itself, this is 
equivalent to storing the 16-bit value 1080H in the 80186 CPU's native order. 

The following sections describe the individual request and reply messages, 
including a detailed description of the data fields unique to each request. The 
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Figure 11-3: Encapsulation of Request/Reply Message 



diagrams for these messages do not show the individual Ethernet fields or the 
standard message header fields. Offset addresses shown for the messages are 
calculated from the beginning of the standard message header (at the subtype 
field). 

11.6. FIND AND SELECT REQUEST/REPLY MESSAGES 

The FIND and SELECT request messages are described together here because 
their format, shown in Figure 11-4, is identical. The EXOS Intelligent Ethernet 
Controller broadcasts the FIND request message to identify bootstrap servers, 
which return a FIND reply message to the client's physical address. The EXOS 
Intelligent Ethernet Controller then sends the SELECT request message to the 
physical address of a boot server, telling it to bootstrap the EXOS Intelligent 
Ethernet Controller. The boot server acknowledges this with a SELECT reply 
message. The following paragraphs describe the individual fields in detail. 
Unless otherwise stated, each field's function is identical in FIND and SELECT 
messages. 

11.6.1. Standard Message Header Fields 

The EXOS Intelligent Ethernet Controller writes a unique value into the 
message ID field in each request message. The boot server should return this 
same value in the reply message, enabling the EXOS Intelligent Ethernet 
Controller to associate the two. 
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Figure 11-4: Network Bootstrap FIND/SELECT Request/Reply Message 



The request code field's value in the FIND request is 4, in the SELECT request 
5. The boot server should return the same value in the reply message. 

The reply code field should be in both request and reply messages. 

The message length field contains the value 106 in the request messages. Its 
value in the reply message should be 26. 

11.6.2. Protocol Version Field 

The protocol version field contains the revision level of the network bootstrap 
protocol supported by the EXOS Intelligent Ethernet Controller. Boot servers 
can examine this field to check that they are compatible with the client's version. 
It is interpreted as a simple 16-bit numeric value. The current boot protocol 
version is 1 for all EXOS 200 Series boards. The boot server should preserve 
this value in the reply message. 
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11.6.3. Number of Buffers Field 

The number of buffers field tells the boot server how many buffers the client 
EXOS Intelligent Ethernet Controller provides for processing COMMAND 
requests. This determines how many outstanding requests the boot server 
should allow at any time. Its current value is 1. The boot server should 
preserve this value in the reply message. 

11.6.4. Buffer Length Field 

The buffer length field specifies the length of the EXOS Intelligent Ethernet 
Controller's receive buffer. This determines the maximum size COMMAND 
request packets the EXOS Intelligent Ethernet Controller can receive, excluding 
the 4-byte CRC field. Its current value is 508 bytes. The boot server should 
preserve this value in the reply message. 

11.6.5. Station ID Field 

The station ID field contains the physical address, in standard Ethernet format, 
of the party to which a message pertains. While this is normally the same as a 
packet's source address field, this is not necessarily the case. A bootstrap 
server might place a different boot server's address in this field in order to "hand 
off" a boot session. The EXOS Intelligent Ethernet Controller examines this field 
in FIND and SELECT reply messages to determine the boot server's 
physical address. 

The boot server should examine this field to determine the client's physical 
address, as well. The EXOS Intelligent Ethernet Controller will always place its 
effective physical address in this field. 

11.6.6. Session ID Field 

The session ID field is undefined in the FIND request and reply messages. It is 
also undefined in the SELECT request message. In the SELECT reply 
message, the boot server should return a unique value in this field which 
identifies the boot session just established. The EXOS Intelligent Ethernet 
Controller will then accept COMMAND request messages only if the first 12 
bytes of their message ID field matches this value. 

1 1 .6.7. Receive Wait Timeout Field 

The receive wait timeout field is used to negotiate the timeout interval which the 
EXOS Intelligent Ethernet Controller observes when waiting for some message 
from the boot server. It is specified in milliseconds, but the EXOS Intelligent 
Ethernet Controller will round it up to the next 20-millisecond interval if it is not 
an even multiple of 20. In the FIND request message, the EXOS Intelligent 
Ethernet Controller declares the current value, which is 3000 milliseconds by 
default. The default value is in force after a reset, and is reinstated whenever 
the EXOS Intelligent Ethernet Controller performs a FIND request retry. 
Therefore the EXOS Intelligent Ethernet Controller will timeout and retry if it has 
not received a FIND reply message within 3 seconds after sending the FIND 
request. 

The boot server can specify a different value in the FIND reply message, and 
the EXOS Intelligent Ethernet Controller will copy this value (subject to rounding) 
into the SELECT request message. In the SELECT reply message, the boot 
server can once again specify a different value. In either reply message, the 
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value OFFH selects the current value. If the value specified is 0, then the EXOS 
Intelligent Ethernet Controller will not timeout, but will wait indefinitely. This is 
useful for debugging purposes. 

11.6.8. Configuration Message Field 

The configuration message field is defined only for the FIND and SELECT 
request messages. The reply messages do not include this field and the boot 
server need not allocate space for it in the message length field. Its format is 
exactly identical to the configuration message described in the appropriate 
Initialization and Host Interface chapter, the section being titled; Configuration 
Message Format, it should be interpreted as though it were a configuration reply 
message. It describes the current configuration of the EXOS Intelligent Ethernet 
Controller, which will express all the default values if the board has just been 
reset. If the board has been configured previously (which may occur if initialized 
by a host system) then it will reflect any modifications made since reset time. 

Also included in this field is the EXOS Context information which indicates the 
EXOS 200 Series controller board in use at the requesting end. For the EXOS 
Intelligent Ethernet Controller the Context value is 01. A boot server must check 
this field to assure that the value indicates a product that the boot server is 
designed to serve. 

11.7. DOWNLOAD REQUEST/REPLY MESSAGE 

The bootstrap server can use the DOWNLOAD request message to download 
code and data to the EXOS Intelligent Ethernet Controller's RAM. Any area of 
memory normally available to the user can be used. Figure 11-5 shows the 
format of the request message, and the following paragraphs describe its 
individual fields in detail. 

11.7.1. Standard Message Header Fields 

The boot server should write the session ID into the first 12 bytes of the 
message ID field in each request message. The remaining 4 bytes may be 
used for any purpose which suits the boot server. In the reply message, the 
EXOS Intelligent Ethernet Controller will preserve this entire field's value. 

The request code field's value for the DOWNLOAD request is 0. The EXOS 
Intelligent Ethernet Controller returns the same value in the reply message. 

The reply code field should be in the request message. In the reply 
message, it reports the status of the DOWNLOAD request. 

Successful completion. 

A3H Destination memory block overlaps the memory reserved for NX 
200, no copy done. 

A1H Invalid request. 

The message length field will depend on the length of the data field in the 
request message. Its value in the reply message is 10. 

11.7.2. Load Length Field 

The load length field specifies the length of the data field in the request 
message. In the reply message, this field returns the number of bytes actually 
downloaded into EXOS Intelligent Ethernet Controller memory. 
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# Length Offset Field Name 



Request Reply 



1 ) 22 



2) 2 



3) 4 



4) 4 



5) n 



22 



24 



28 



32 



Standard Message Header Fields : see text see text 



Load Length 



Rese r ved 



Data 

(in request message only) 



see text see t ex t 



I zero 



EXOS Down -Load Address 



unde fined 



I see text p rese r ved 



see text 



I < 1 byte > I 

Figure 11-5: Network Bootstrap DOWNLOAD Request/Reply Message 



11.7.3. Reserved Field 



The reserved field should contain zeros in the request message. Its value is 
undefined in the reply message. 

11.7.4. EXOS Download Address Field 

The EXOS download address field specifies the address in EXOS Intelligent 
Ethernet Controller memory to which the data should be transferred. Note that, 
as with all addresses referring to locations in EXOS memory, this should be a 
segmented address in the 8086 style. Its value is preserved in the 
reply message. 

11.7.5. Data Field 

In the request message, the data field contains the data to be downloaded. 
Given the current receive buffer size of 508 bytes, the maximum size of this field 
is 462 bytes. The data field is not defined in the reply message, nor should 
space be allocated for it there. 

11.8. UPLOAD REQUEST/REPLY MESSAGE 

The bootstrap server can use the UPLOAD request to read data from the EXOS 
Intelligent Ethernet Controller's RAM. It is similar to the DOWNLOAD request, 
except that the data field is defined for the reply message instead of the request 
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message. Figure 11-6 shows the format of the request message, and the 
following paragraphs describe its individual fields in detail. 



# Length Offset Field Name 



Request Reply 



1 ) 22 



Standard Message Header Fields see text see text 



2) 2 



22 



Load Length 



see text see t ex t 



3) 4 



24 



Rese r ved 



zero 



unde f i ned 



28 



EXOS Up- I oad Address 



see text p rese r ved 



5) n 



32 



Data 

(in reply message only) 



see text 



I - 1 byte •■ I 

Figure 11-6: Network Bootstrap UPLOAD Request/Reply Message 



11.8.1. Standard Message Header Fields 

The boot server should write the session ID into the first 12 bytes of the 
message ID field in each request message. The remaining 4 bytes may be 
used for any purpose which suits the boot server. In the reply message, the 
EXOS Intelligent Ethernet Controller will preserve this entire field's value. 

The request code field's value for the UPLOAD request is 1. The EXOS 
Intelligent Ethernet Controller returns the same value in the reply message. 

The reply code field is should be in the request message. In the reply 
message, it reports the status of the UPLOAD request: 

Successful completion. 

A3H Specified memory does not exist, no copy done. 

A1H Invalid request. 

The message length field's value in the request message should be 10. Its 
value in the reply message will depend on the length of the data field. 
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11.8.2. Load Length Field 

The load length field in the request message specifies the number of bytes to be 
read from the EXOS Intelligent Ethernet Controller's memory. In the reply 
message, this field returns the number of bytes actually read from EXOS 
Intelligent Ethernet Controller memory. 

11.8.3. Reserved Field 

The reserved field should contain zeros in the request message. Its value in the 
reply message is undefined. 

11.8.4. EXOS Upload Address Field 

The EXOS upload address field in the request message specifies the address in 
EXOS Intelligent Ethernet Controller memory from which to read data. In the 
reply message, its value is preserved. 

11.8.5. Data Field 

The data field is not defined in the request message, nor should space be 
allocated for it there. In the reply message, the data field contains the data read 
from EXOS memory. As in the DOWNLOAD command, this is constrained by 
the current receive buffer size of 508 bytes; its maximum size is 462 bytes. 

11.9. CONFIGURE REQUEST/REPLY MESSAGE 

The bootstrap server can use the CONFIGURE request to modify the EXOS 
Intelligent Ethernet Controller's configuration, just as the host would at 
initialization time (see the appropriate Initialization and Host Interface). Normally, 
a boot server performs configuration with its first COMMAND request message, 
before downloading software; after configuration the contents of user memory 
on the EXOS Intelligent Ethernet Controller is not defined. However, 
configuration is not mandatory; if neglected, all configuration options will retain 
their current values, or the default values if the board has not been configured 
since reset. Figure 11-7 shows the format of the request message, and the 
following paragraphs describe its individual fields in detail. 



# Length Offset Field Name Request Reply 

1) 22 : Standard Message Header Fields see text see text 



2) 80 22 : Configuration Message see text see text 

(in request messages only) 



I- - - - - 1 byte 

Figure 11-7: Network Bootstrap CONFIGURE Request/Reply Message 
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11.9.1. Standard Message Header Fields 

The boot server should write the session ID into the first 12 bytes of the 
message ID field in each request message. The remaining 4 bytes may be 
used for any purpose which suits the boot server. In the reply message, the 
EXOS Intelligent Ethernet Controller will preserve this entire field's value. 

The request code field's value for the CONFIGURE request is 3. The EXOS 
Intelligent Ethernet Controller returns the same value in the reply message. 

The reply code field should be in the request message. In the reply 
message, its value is the same as the configuration message's Completion 
Code field. 

The message length field's value in the request message should be 80. This 
value is preserved in the reply message. 

11.9.2. Configuration Message Field 

The configuration message field is exactly equivalent to the configuration 
message described in the appropriate Initialization and Host Interface section. 
There are some slight semantic differences which apply to net boot mode. For 
instance, in the request message, the number of hosts field may be 0. If so, 
then all the following fields, which specify host message queue parameters, are 
undefined. The EXOS operation mode field must always be set to 2, for net 
boot mode. In the reply message, it will always return this value. 

11.10. EXECUTE REQUEST/REPLY MESSAGE 

The boot server can use the EXECUTE request message to start execution of 
code it has downloaded to the EXOS Intelligent Ethernet Controller. Once the 
EXOS Intelligent Ethernet Controller receives this command, it will ignore all 
network bootstrap type packets. The initial process runs exactly the same as 
one initialized by a host system (see Initialization and Host Interface; the 
Configuration Message Format section). 



# Length Offset Field Name Request Reply 



1 ) 22 Standard Message Header Fields see text see text 

I - I 

2) 4 22 I Starting Address I see text preserved 



I - -. 1 byte 

Figure 11-8: Network Bootstrap EXECUTE Request/Reply Message 
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Figure 11-8 shows the format of the EXECUTE request/reply message, and the 
following paragraphs explain its individual fields in detail. 

11.10.1. Standard Message Header Fields 

The boot server should write the session ID into the first 12 bytes of the 
message ID field in each request message. The remaining 4 bytes may be 
used for any purpose which suits the boot server. In the reply message, the 
EXOS Intelligent Ethernet Controller will preserve this entire field's value. 

The request code field's value for the EXECUTE request is 2. The EXOS 
Intelligent Ethernet Controller returns the same value in the reply message. 

The reply code field should be in the request message. In the reply 
message, it reports the status of the EXECUTE request: 

Successful completion. 

A1H Invalid request. 

A2H Invalid starting address. 

The message length field's value in both the request and reply messages 
should be 4. 

11.10.2. Starting Address Field 

The starting address field specifies the initial value of the initial process's 
program counter. Its value is preserved in the reply message. 
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Appendix A 
SELF-DIAGNOSTICS and CONFIGURATION ERRORS 

A.1. INTRODUCTION 

The NX 200 firmware performs a Series of tests which exercise the hardware 
and software components of the EXOS Intelligent Ethernet Controller. In 
addition to ensuring the EXOS board is functioning properly, the tests can 
isolate specific software or hardware errors associated with configuration or 
operation. The errors are reported via an LED making it possible for them to be 
identified and corrected. 

This appendix contains information pertinent to the NX 200 self-tests, 
configuration errors and error codes. 

A.2. SELF-TEST OPERATION 

When NX 200 is reset by either the initialization signal or by host software (refer 
to Sections 2, 3, 4, or 5 as applicable to the specific system bus), NX firmware 
runs comprehensive diagnostic tests on EXOS Intelligent Ethernet Controller 
components. These tests complete within 3 seconds, whereupon the board is 
ready for configuration.. If the tests fail, this is reported to the host via an I/O 
port (see Chapter 2.1). 

A.2.1. NX 200 Status LED 

Test progress and status are also reported via an LED at position DS1 (on the 
EXOS board). Upon EXOS board reset this LED is lit, and remains lit constantly 
while self tests are in progress. When self tests are complete, the LED flashes 
evenly until the EXOS Intelligent Ethernet Controller is initialized by the host or 
from the Ethernet. After initialization, LED DS1 is turned off. 

If diagnostics indicate a hardware problem, then the LED will either be lit 
constantly, or communicate an error code by flashing long and short (Morse 
code-like) pulses. Software errors during the process of configuration can also 
result in an error code display. Error codes are 8-bit numbers, and are 
presented bit-by-bit, starting with the most significant bit. A long pulse is a 1 bit, 
and a short pulse is a bit. The error code is continuously repeated, with a 
pause in between to demarcate the starting point. Table A-1 specifies all 
defined error codes for NX 200 on the EXOS Intelligent Ethernet Controller. 

A.2.2. Error Handling 

As stated earlier, NX 200 handles all Ethernet error conditions, including user 
software configuration, and native hardware errors. Additionally, NX 200 also 
monitors for fatal hardware and software errors during general 
network operation. 
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A.3. ERROR CATEGORIES 

The errors are logically categorized into three groups. 

• AOH-AFH: Fatal software configuration errors 

• BOH-BFH: Fatal hardware errors 

• COH-CFH: Fatal errors, either software or hardware, which occur 
during the course of normal operation 

A. 3.1 Fatal Software Errors 

The software generated error codes are available and useful for debugging user 
software written to configure the Ethernet utilizing non-EXOS, user proprietary 
protocols. Although software configuration errors generally occur from entering 
inappropriate values for configuration, on rare occasions, they can result from a 
bad bit in a memory chip being interpreted by NX 200 as an invalid 
value returned. 

An exception to this is error AFH - Net Boot Failed which results from utilizing 
the network bootstrap procedures for diskless workstations. This function, 
associated with the EXOS Intelligent Ethernet Controller jumper option (J6), is 
not currently implemented in the NX 200 operating system kernel. 

A.3.2 Fatal Hardware Errors 

The fatal hardware errors generally occur when NX 200 encounters specific 
EXOS hardware failure. In such a case, it will be necessary to contact Excelan. 

However, the following three errors can be exceptions to this case, and may be 
due to incorrectly seated or installed cabling. In the event these errors occur, 
check and reconnect the cables, then reset the system. If this does not correct 
the condition and the error continues to occur, contact Excelan. 

BBH - Transmission Test Failed 

BCH - Receive Test Failed 

BDH - Local Loopback Data Path Test Failed 

The third and final category is directly associated with fatal errors which occur 
during normal operation, and are not usually encountered upon executing a 
reset and standard self-test. These errors can be produced by either software, 
hardware, or a combination of both. The software errors may be intermittent, 
while the hardware errors may be misconnections between the host and the 
network, or host and EXOS Intelligent Ethernet Controller. 
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The five errors below are generally associated with the physical interface 
between the host and the EXOS 200 Series board. 

C1 H - Host Memory Read/Write Test Failed 

C9H - NMI Interrupt for Bus Timeout Failed 

CAH - Host Interrupt Test Failed 

CCH - Divide Error Exception 

CDH - Undefined Interrupt Type 

One error, CBH - Command Unit Test Failed, can occur between the host and 
the network, if the transceiver malfunctions or is physically not connected to the 
network. If such is the case reconnect the host to the network and reboot, 
repetition of the error code will usually isolate the error to a 
transceiver malfunction. 
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Table A-1 : Self-Diagnostic and Configuration Error Codes 



Hex Code Pulse Code 



Software Generated Errors: 



AOH 


-.- 




A4H 


-.- 




A5H 


-.- 




A7H 


-.- 




A8H 


-.- 




A9H 


-.- 




AAH 


-.- 




ABH 


-.- 




ACH 


-.- 




ADH 


-.- 




AEH 


-.- 




AFH 


-.- 




Hardware Generated Errors: 


BOH 


-.- 




B1H 


-.- 




B2H 


-.- 




B3H 


-.- 




B4H 


-.- 




B5H 


-.- 




B6H 


-.- 




B7H 


-.- 




B8H 


-.- 




B9H 


-.- 




BAH 


-.- 




BBH 


-.- 




BCH 


-.- 




BDH 


-.- 




BEH 


-.- 




BFH 


-.- 





Operation Generated Errors: 


COH 


- 




C1H 


-- 




C8H 


- 




C9H 


-- 




CAH 


- 




CBH 


-- 




CCH 


- 




CDH 


- 




CEH 


- 




CFH 


"~ 


. 



Explanation of Error Code 



Invalid address for configuration message. 
Invalid operation mode parameter. 
Invalid host data format test pattern 
Invalid configuration message format. 
Invalid movable data block parameter. 
Invalid number of processes parameter. 
Invalid number of mailboxes parameter. 
Invalid number of address slots parameter. 
Invalid number of hosts parameter. 
Invalid host queue parameter. 
Improper objects allocation. 
Net boot failed. 



Checksum on NX 200 EPROM failed. 

Memory test failed for 0-1 28K. 

Memory test failed for 128K up to the highest address. 

Counter test failed. 

Interrupts test failed. 

Transmission test failed. 

Receive test failed. 

Local loopback data path test failed 

CRC test failed. 

Checksum on physical address EPROM failed. 

System error. 

Ethernet chip initialization failed. 

Ethernet chip self-test failed. 

Ethernet chip resource counter failed. 

External loop-back test alignment error. 

SBX board not in place 



Specified time exhausted. 

Host memory read/write test failed. 

Parity hardware logic failed. 

NMI interrupt for bus timeout failed. 

Host interrupt test failed. 

Command unit test failed. 

Divide error exception. 

Undefined interrupt type. 

Command not executed by the CU of the 82586. 

Command block sync failed between h/w and s/w. 
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